[Yahoo-eng-team] [Bug 2028409] Re: Add domain_id config option to remove the need of cloud admin user when generating dynamic credentials
** 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/2028409
Title:
Add domain_id config option to remove the need of cloud admin user
when generating dynamic credentials
Status in OpenStack Identity (keystone):
New
Status in tempest:
In Progress
Bug description:
Currently generating dynamic credentials requires listing domains and
filter the result by domain name to get the current/admin domain
object from Keystone API (through `/v3/domains` API). And as stated in
the default keystone policy, listing domains requires cloud_admin
privilege, which means we cannot use a domain admin to create test
accounts with tempest.
```
"identity:list_domains": "rule:cloud_admin",
```
A better behavior would be using `/v3/domains/{domain_id}` API to get
the domain object directly so that only a domain admin user is needed
to generate test accounts. The benefit of reducing required user
privileges is isolating test environment. This requires adding an
additional domain_id configuration option in [auth] section.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/2028409/+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 2028851] Re: Console output was empty in test_get_console_output_server_id_in_shutoff_status
test_get_console_output_server_id_in_shutoff_status test was always wrong since starting which used to get the console for the server created in the setup method and is in active state. This test never tried to get the console of the shutoff server. It is still unknown how this wrong test started failing after the test refactoring in this commit https://review.opendev.org/c/openstack/tempest/+/889109 and unhide this issue. This Tempest test corrects the tempest test, which will always fail because the test expects the console of *shutoff* Guest also, which is not something returned by Nova. Nova does not return the server console for the shutoff server. There is an open question on Nova's behaviours: 1. What should Nova return the console output of the shutoff guest 2. what status code should Nova return in case the "console is not available"? Currently, it returns 404. There is some discussion over this topic in IRC: - hhttps://meetings.opendev.org/irclogs/%23openstack-nova/%23openstack-nova.2023-07-27.log.html#t2023-07-27T18:50:03 ** Changed in: nova Status: Invalid => 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/2028851 Title: Console output was empty in test_get_console_output_server_id_in_shutoff_status Status in OpenStack Compute (nova): New Status in tempest: Confirmed Bug description: test_get_console_output_server_id_in_shutoff_status https://github.com/openstack/tempest/blob/04cb0adc822ffea6c7bfccce8fa08b03739894b7/tempest/api/compute/servers/test_server_actions.py#L713 is failing consistently in the nova-lvm job starting on July 24 with 132 failures in the last 3 days. https://tinyurl.com/kvcc9289 Traceback (most recent call last): File "/opt/stack/tempest/tempest/api/compute/servers/test_server_actions.py", line 728, in test_get_console_output_server_id_in_shutoff_status self.wait_for(self._get_output) File "/opt/stack/tempest/tempest/api/compute/base.py", line 340, in wait_for condition() File "/opt/stack/tempest/tempest/api/compute/servers/test_server_actions.py", line 213, in _get_output self.assertTrue(output, "Console output was empty.") File "/usr/lib/python3.10/unittest/case.py", line 687, in assertTrue raise self.failureException(msg) AssertionError: '' is not true : Console output was empty. its not clear why this has started failing. it may be a regression or a latent race in the test that we are now failing. def test_get_console_output_server_id_in_shutoff_status(self): """Test getting console output for a server in SHUTOFF status Should be able to GET the console output for a given server_id in SHUTOFF status. """ # NOTE: SHUTOFF is irregular status. To avoid test instability, # one server is created only for this test without using # the server that was created in setUpClass. server = self.create_test_server(wait_until='ACTIVE') temp_server_id = server['id'] self.client.stop_server(temp_server_id) waiters.wait_for_server_status(self.client, temp_server_id, 'SHUTOFF') self.wait_for(self._get_output) the test does not wait for the VM to be sshable so its possible that we are shutting off the VM before it is fully booted and no output has been written to the console. this failure has happened on multiple providers but only in the nova-lvm job. the console behavior is unrelated to the storage backend but the lvm job i belive is using lvm on a loopback file so the storage performance is likely slower then raw/qcow. so perhaps the boot is taking longer and no output is being written. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2028851/+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 2027817] Re: neutron slow jobs before xena broken with ERROR: unknown environment 'slow'
marking invalid for neutron as fix is in tempest https://review.opendev.org/c/openstack/tempest/+/888590 ** Changed in: tempest Status: New => Fix Committed ** 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/2027817 Title: neutron slow jobs before xena broken with ERROR: unknown environment 'slow' Status in neutron: Invalid Status in tempest: Fix Committed Bug description: Broken since https://review.opendev.org/c/openstack/tempest/+/887237 merged as neutron slow jobs inherit from tempest-slow-py3. These fails with ERROR: unknown environment 'slow' In releases before xena tempest is pinned and don't have the patch[1] which added slow toxenv. The job needs to be fixed such that these use available toxenv. Build failures:- https://zuul.opendev.org/t/openstack/builds?job_name=neutron-tempest- slow-py3=openstack/neutron Example failure:- https://1aa32956600eed195a6f-1e93f2912422e0b9805cacc7d195dee2.ssl.cf1.rackcdn.com/887279/1/gate/neutron- tempest-slow-py3/c9ff905/job-output.txt [1] https://github.com/openstack/tempest/commit/6bb98c2aa478f7ad32838fec4b59c4acb73ccf21 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2027817/+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 2027817] Re: neutron slow jobs before xena broken with ERROR: unknown environment 'slow'
** 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 neutron. https://bugs.launchpad.net/bugs/2027817 Title: neutron slow jobs before xena broken with ERROR: unknown environment 'slow' Status in neutron: Triaged Status in tempest: New Bug description: Broken since https://review.opendev.org/c/openstack/tempest/+/887237 merged as neutron slow jobs inherit from tempest-slow-py3. These fails with ERROR: unknown environment 'slow' In releases before xena tempest is pinned and don't have the patch[1] which added slow toxenv. The job needs to be fixed such that these use available toxenv. Build failures:- https://zuul.opendev.org/t/openstack/builds?job_name=neutron-tempest- slow-py3=openstack/neutron Example failure:- https://1aa32956600eed195a6f-1e93f2912422e0b9805cacc7d195dee2.ssl.cf1.rackcdn.com/887279/1/gate/neutron- tempest-slow-py3/c9ff905/job-output.txt [1] https://github.com/openstack/tempest/commit/6bb98c2aa478f7ad32838fec4b59c4acb73ccf21 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2027817/+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 2025096] Re: test_rebuild_volume_backed_server failing 100% on ceph job
as fix was in devstack, i am marking rest other projects as invalid.
Thanks Dan, Rajat for working on this.
** Changed in: tempest
Status: New => Invalid
** Also affects: devstack
Importance: Undecided
Status: New
** Changed in: devstack
Status: New => Fix Committed
** Changed in: devstack-plugin-ceph
Status: New => Invalid
** Changed in: cinder
Status: Confirmed => Invalid
** Changed in: nova
Status: Confirmed => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2025096
Title:
test_rebuild_volume_backed_server failing 100% on ceph job
Status in Cinder:
Invalid
Status in devstack:
Fix Committed
Status in devstack-plugin-ceph:
Invalid
Status in OpenStack Compute (nova):
Invalid
Status in tempest:
Invalid
Bug description:
There is some issue in ceph job during password injection
during the rebuild operation, and due to that test is failing 100% failure on
ceph job.
These test pass on other jobs like tempest-full-py3
Failure logs:
-
https://b932a1446345e101b3ef-4740624f0848c8c3257f704064a4516f.ssl.cf5.rackcdn.com/883557/2/check/nova-
ceph-multistore/d7db64f/testr_results.html
Response - Headers: {'date': 'Mon, 26 Jun 2023 01:07:28 GMT', 'server':
'Apache/2.4.52 (Ubuntu)', 'x-openstack-request-id':
'req-f707a2bb-a7c6-4e65-93e2-7cb8195dd331', 'connection': 'close', 'status':
'204', 'content-location':
'https://10.209.99.44:9696/networking/v2.0/security-groups/63dc9e50-2d05-4cfa-912d-92a3c9283e42'}
Body: b''
2023-06-26 01:07:28,442 108489 INFO [tempest.lib.common.rest_client]
Request (ServerActionsV293TestJSON:_run_cleanups): 404 GET
https://10.209.99.44:9696/networking/v2.0/security-groups/63dc9e50-2d05-4cfa-912d-92a3c9283e42
0.034s
2023-06-26 01:07:28,442 108489 DEBUG[tempest.lib.common.rest_client]
Request - Headers: {'Content-Type': 'application/json', 'Accept':
'application/json', 'X-Auth-Token': ''}
Body: None
Response - Headers: {'date': 'Mon, 26 Jun 2023 01:07:28 GMT', 'server':
'Apache/2.4.52 (Ubuntu)', 'content-type': 'application/json', 'content-length':
'146', 'x-openstack-request-id': 'req-ae967163-b104-4ddf-b1e8-bb6da298b498',
'connection': 'close', 'status': '404', 'content-location':
'https://10.209.99.44:9696/networking/v2.0/security-groups/63dc9e50-2d05-4cfa-912d-92a3c9283e42'}
Body: b'{"NeutronError": {"type": "SecurityGroupNotFound", "message":
"Security group 63dc9e50-2d05-4cfa-912d-92a3c9283e42 does not exist", "detail":
""}}'
2023-06-26 01:07:29,135 108489 INFO [tempest.lib.common.rest_client]
Request (ServerActionsV293TestJSON:_run_cleanups): 204 DELETE
https://10.209.99.44:9696/networking/v2.0/floatingips/c6cc0747-06bd-4783-811d-2408a72db3cc
0.692s
2023-06-26 01:07:29,135 108489 DEBUG[tempest.lib.common.rest_client]
Request - Headers: {'Content-Type': 'application/json', 'Accept':
'application/json', 'X-Auth-Token': ''}
Body: None
Response - Headers: {'date': 'Mon, 26 Jun 2023 01:07:29 GMT', 'server':
'Apache/2.4.52 (Ubuntu)', 'x-openstack-request-id':
'req-e0797282-5cc1-4d86-b2ec-696feed6369a', 'connection': 'close', 'status':
'204', 'content-location':
'https://10.209.99.44:9696/networking/v2.0/floatingips/c6cc0747-06bd-4783-811d-2408a72db3cc'}
Body: b''
}}}
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/lib/common/ssh.py", line 136, in
_get_ssh_connection
ssh.connect(self.host, port=self.port, username=self.username,
File
"/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/paramiko/client.py",
line 365, in connect
sock.connect(addr)
TimeoutError: timed out
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/common/utils/__init__.py", line 70, in
wrapper
return f(*func_args, **func_kwargs)
File
"/opt/stack/tempest/tempest/api/compute/servers/test_server_actions.py", line
927, in test_rebuild_volume_backed_server
linux_client.validate_authentication()
File "/opt/stack/tempest/tempest/lib/common/utils/linux/remote_client.py",
line 31, in wrapper
return function(self, *args, **kwargs)
File "/opt/stack/tempest/tempest/lib/common/utils/linux/remote_client.py",
line 123, in validate_authentication
self.ssh_client.test_connection_auth()
File "/opt/stack/tempest/tempest/lib/common/ssh.py", line 245, in
test_connection_auth
connection = self._get_ssh_connection()
File "/opt/stack/tempest/tempest/lib/common/ssh.py", line 155, in
_get_ssh_connection
raise exceptions.SSHTimeout(host=self.host,
tempest.lib.exceptions.SSHTimeout: Connection to the 172.24.5.20 via SSH
timed out.
User: cirros, Password: rebuildPassw0rd
To manage notifications about
[Yahoo-eng-team] [Bug 2025096] Re: test_rebuild_volume_backed_server failing 100% on ceph job
** Also affects: nova
Importance: Undecided
Status: New
** Also affects: cinder
Importance: Undecided
Status: New
** Also affects: devstack-plugin-ceph
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/2025096
Title:
test_rebuild_volume_backed_server failing 100% on ceph job
Status in Cinder:
New
Status in devstack-plugin-ceph:
New
Status in OpenStack Compute (nova):
New
Status in tempest:
New
Bug description:
There is some issue in ceph job during password injection
during the rebuild operation, and due to that test is failing 100% failure on
ceph job.
These test pass on other jobs like tempest-full-py3
Failure logs:
-
https://b932a1446345e101b3ef-4740624f0848c8c3257f704064a4516f.ssl.cf5.rackcdn.com/883557/2/check/nova-
ceph-multistore/d7db64f/testr_results.html
Response - Headers: {'date': 'Mon, 26 Jun 2023 01:07:28 GMT', 'server':
'Apache/2.4.52 (Ubuntu)', 'x-openstack-request-id':
'req-f707a2bb-a7c6-4e65-93e2-7cb8195dd331', 'connection': 'close', 'status':
'204', 'content-location':
'https://10.209.99.44:9696/networking/v2.0/security-groups/63dc9e50-2d05-4cfa-912d-92a3c9283e42'}
Body: b''
2023-06-26 01:07:28,442 108489 INFO [tempest.lib.common.rest_client]
Request (ServerActionsV293TestJSON:_run_cleanups): 404 GET
https://10.209.99.44:9696/networking/v2.0/security-groups/63dc9e50-2d05-4cfa-912d-92a3c9283e42
0.034s
2023-06-26 01:07:28,442 108489 DEBUG[tempest.lib.common.rest_client]
Request - Headers: {'Content-Type': 'application/json', 'Accept':
'application/json', 'X-Auth-Token': ''}
Body: None
Response - Headers: {'date': 'Mon, 26 Jun 2023 01:07:28 GMT', 'server':
'Apache/2.4.52 (Ubuntu)', 'content-type': 'application/json', 'content-length':
'146', 'x-openstack-request-id': 'req-ae967163-b104-4ddf-b1e8-bb6da298b498',
'connection': 'close', 'status': '404', 'content-location':
'https://10.209.99.44:9696/networking/v2.0/security-groups/63dc9e50-2d05-4cfa-912d-92a3c9283e42'}
Body: b'{"NeutronError": {"type": "SecurityGroupNotFound", "message":
"Security group 63dc9e50-2d05-4cfa-912d-92a3c9283e42 does not exist", "detail":
""}}'
2023-06-26 01:07:29,135 108489 INFO [tempest.lib.common.rest_client]
Request (ServerActionsV293TestJSON:_run_cleanups): 204 DELETE
https://10.209.99.44:9696/networking/v2.0/floatingips/c6cc0747-06bd-4783-811d-2408a72db3cc
0.692s
2023-06-26 01:07:29,135 108489 DEBUG[tempest.lib.common.rest_client]
Request - Headers: {'Content-Type': 'application/json', 'Accept':
'application/json', 'X-Auth-Token': ''}
Body: None
Response - Headers: {'date': 'Mon, 26 Jun 2023 01:07:29 GMT', 'server':
'Apache/2.4.52 (Ubuntu)', 'x-openstack-request-id':
'req-e0797282-5cc1-4d86-b2ec-696feed6369a', 'connection': 'close', 'status':
'204', 'content-location':
'https://10.209.99.44:9696/networking/v2.0/floatingips/c6cc0747-06bd-4783-811d-2408a72db3cc'}
Body: b''
}}}
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/lib/common/ssh.py", line 136, in
_get_ssh_connection
ssh.connect(self.host, port=self.port, username=self.username,
File
"/opt/stack/tempest/.tox/tempest/lib/python3.10/site-packages/paramiko/client.py",
line 365, in connect
sock.connect(addr)
TimeoutError: timed out
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/common/utils/__init__.py", line 70, in
wrapper
return f(*func_args, **func_kwargs)
File
"/opt/stack/tempest/tempest/api/compute/servers/test_server_actions.py", line
927, in test_rebuild_volume_backed_server
linux_client.validate_authentication()
File "/opt/stack/tempest/tempest/lib/common/utils/linux/remote_client.py",
line 31, in wrapper
return function(self, *args, **kwargs)
File "/opt/stack/tempest/tempest/lib/common/utils/linux/remote_client.py",
line 123, in validate_authentication
self.ssh_client.test_connection_auth()
File "/opt/stack/tempest/tempest/lib/common/ssh.py", line 245, in
test_connection_auth
connection = self._get_ssh_connection()
File "/opt/stack/tempest/tempest/lib/common/ssh.py", line 155, in
_get_ssh_connection
raise exceptions.SSHTimeout(host=self.host,
tempest.lib.exceptions.SSHTimeout: Connection to the 172.24.5.20 via SSH
timed out.
User: cirros, Password: rebuildPassw0rd
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/2025096/+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 1998148] [NEW] nova-lvm job failing for volume detach timeout
Public bug reported:
nova-lvm job started failing 100% on few volume detach tests. It started
failing when we move it to run on Ubuntu jammy (22.04).
Below tests are failing::
tearDownClass (tempest.api.compute.servers.test_server_rescue
ServerStableDeviceRescueTest)
tempest.api.compute.servers.test_server_rescue.ServerStableDeviceRescueTest.test_stable_device_rescue_disk_virtio_with_volume_attached[id-a3772b42-00bf-4310-a90b-1cc6fd3e7eab,volume]
tempest.api.compute.servers.test_server_rescue_negative.ServerRescueNegativeTestJSON.test_rescued_vm_detach_volume[id-f56e465b-fe10-48bf-b75d-646cda3a8bc9,negative,volume]
tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume[id-52e9045a-e90d-4c0d-9087-79d657fa]
traceback-1: {{{
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/common/waiters.py", line 405, in
wait_for_volume_attachment_remove_from_server
raise lib_exc.TimeoutException(message)
tempest.lib.exceptions.TimeoutException: Request timed out
Details: Volume 8bb34af9-d48d-4ee4-b534-2356b08e3a65 failed to detach from
server c4cab756-e4b2-44c9-9a50-6115608cf467 within the required time (196 s)
from the compute API perspective
}}}
traceback-2: {{{
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/common/waiters.py", line 337, in
wait_for_volume_resource_status
raise lib_exc.TimeoutException(message)
tempest.lib.exceptions.TimeoutException: Request timed out
Details: volume 8bb34af9-d48d-4ee4-b534-2356b08e3a65 failed to reach available
status (current in-use) within the required time (196 s).
}}}
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/api/compute/volumes/test_attach_volume.py",
line 115, in test_attach_detach_volume
waiters.wait_for_volume_resource_status(
File "/opt/stack/tempest/tempest/common/waiters.py", line 337, in
wait_for_volume_resource_status
raise lib_exc.TimeoutException(message)
tempest.lib.exceptions.TimeoutException: Request timed out
Details: volume 8bb34af9-d48d-4ee4-b534-2356b08e3a65 failed to reach available
status (current in-use) within the required time (196 s).
https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_f07/865658/5/check/nova-lvm/f076244/testr_results.html
** 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/1998148
Title:
nova-lvm job failing for volume detach timeout
Status in OpenStack Compute (nova):
New
Bug description:
nova-lvm job started failing 100% on few volume detach tests. It
started failing when we move it to run on Ubuntu jammy (22.04).
Below tests are failing::
tearDownClass (tempest.api.compute.servers.test_server_rescue
ServerStableDeviceRescueTest)
tempest.api.compute.servers.test_server_rescue.ServerStableDeviceRescueTest.test_stable_device_rescue_disk_virtio_with_volume_attached[id-a3772b42-00bf-4310-a90b-1cc6fd3e7eab,volume]
tempest.api.compute.servers.test_server_rescue_negative.ServerRescueNegativeTestJSON.test_rescued_vm_detach_volume[id-f56e465b-fe10-48bf-b75d-646cda3a8bc9,negative,volume]
tempest.api.compute.volumes.test_attach_volume.AttachVolumeTestJSON.test_attach_detach_volume[id-52e9045a-e90d-4c0d-9087-79d657fa]
traceback-1: {{{
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/common/waiters.py", line 405, in
wait_for_volume_attachment_remove_from_server
raise lib_exc.TimeoutException(message)
tempest.lib.exceptions.TimeoutException: Request timed out
Details: Volume 8bb34af9-d48d-4ee4-b534-2356b08e3a65 failed to detach from
server c4cab756-e4b2-44c9-9a50-6115608cf467 within the required time (196 s)
from the compute API perspective
}}}
traceback-2: {{{
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/common/waiters.py", line 337, in
wait_for_volume_resource_status
raise lib_exc.TimeoutException(message)
tempest.lib.exceptions.TimeoutException: Request timed out
Details: volume 8bb34af9-d48d-4ee4-b534-2356b08e3a65 failed to reach
available status (current in-use) within the required time (196 s).
}}}
Traceback (most recent call last):
File
"/opt/stack/tempest/tempest/api/compute/volumes/test_attach_volume.py", line
115, in test_attach_detach_volume
waiters.wait_for_volume_resource_status(
File "/opt/stack/tempest/tempest/common/waiters.py", line 337, in
wait_for_volume_resource_status
raise lib_exc.TimeoutException(message)
tempest.lib.exceptions.TimeoutException: Request timed out
Details: volume 8bb34af9-d48d-4ee4-b534-2356b08e3a65 failed to reach
available status (current in-use) within the required time (196 s).
[Yahoo-eng-team] [Bug 1996836] [NEW] With new RBAC enabled (enforce_scope and enforce_new_defaults): 'router:external' field is missing in network list response
Public bug reported: I was testing the tempest with the new RBAC enabled which means in neutron.conf enable the below options: [oslo_policy] enforce_scope = True enforce_new_defaults = True https://zuul.opendev.org/t/openstack/build/e447385546c749f8b38bc4c411088dc1/log/controller/logs/etc/neutron/neutron_conf.txt#1928 Tempest external network tests doing the list network but 'router:external' field is missing in network list response - https://zuul.opendev.org/t/openstack/build/e447385546c749f8b38bc4c411088dc1/log/job- output.txt#23754 policy defaults for 'router:external' seems fine - https://github.com/openstack/neutron/blob/bf44e70db6219e7f3a45bd61b7dd14a31ae33bb0/neutron/conf/policies/network.py#L193 But it seems enforce_scope is restricting it somewhere, is this check in context causing not to return it? - https://github.com/openstack/neutron-lib/blob/9ecd5995b6c598cee931087bf13fdd166f404034/neutron_lib/context.py#L125 We should not add system:all in neutron as system scope is not supported in neutron policy now. ** Affects: neutron Importance: Undecided Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1996836 Title: With new RBAC enabled (enforce_scope and enforce_new_defaults): 'router:external' field is missing in network list response Status in neutron: In Progress Bug description: I was testing the tempest with the new RBAC enabled which means in neutron.conf enable the below options: [oslo_policy] enforce_scope = True enforce_new_defaults = True https://zuul.opendev.org/t/openstack/build/e447385546c749f8b38bc4c411088dc1/log/controller/logs/etc/neutron/neutron_conf.txt#1928 Tempest external network tests doing the list network but 'router:external' field is missing in network list response - https://zuul.opendev.org/t/openstack/build/e447385546c749f8b38bc4c411088dc1/log/job- output.txt#23754 policy defaults for 'router:external' seems fine - https://github.com/openstack/neutron/blob/bf44e70db6219e7f3a45bd61b7dd14a31ae33bb0/neutron/conf/policies/network.py#L193 But it seems enforce_scope is restricting it somewhere, is this check in context causing not to return it? - https://github.com/openstack/neutron-lib/blob/9ecd5995b6c598cee931087bf13fdd166f404034/neutron_lib/context.py#L125 We should not add system:all in neutron as system scope is not supported in neutron policy now. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1996836/+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 1996129] [NEW] With new RBAC enabled: Tempest test failing on NetworkNotFound
Public bug reported: I was testing the tempest with new RBAC enabled which mean in neutron.conf enable the below options: [oslo_policy] enforce_scope = True enforce_new_defaults = True https://zuul.opendev.org/t/openstack/build/930366c016de49c4b7c26f69b371411a/log/controller/logs/etc/neutron/neutron_conf.txt#1928 In that case tempest tests are failing with NetworkNotFound. For example verfy first test failure in - https://9eed2832462b93d99d63-9a2c0e6b238d9eb37d7a57d0c5074dee.ssl.cf1.rackcdn.com/614484/7/check/tempest-full-enforce-scope-new-defaults/930366c/testr_results.html >From the q-svc log (screen-q-svc.txt): below error is coming from ovn side: [None req-1e9ba6eb-84f1-4091-bf3a-862d6e6cb127 admin admin] Mechanism driver 'ovn' failed in create_network_postcommit: neutron_lib.exceptions.NetworkNotFound: Network 75ccd449-9526-4dc2-96c3-4f76ac9dcbe2 could not be found. compete log: https://zuul.opendev.org/t/openstack/build/930366c016de49c4b7c26f69b371411a/log/controller/logs/screen- q-svc.txt#4406 ** Affects: neutron Importance: Undecided Status: New ** Project changed: tempest => neutron -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1996129 Title: With new RBAC enabled: Tempest test failing on NetworkNotFound Status in neutron: New Bug description: I was testing the tempest with new RBAC enabled which mean in neutron.conf enable the below options: [oslo_policy] enforce_scope = True enforce_new_defaults = True https://zuul.opendev.org/t/openstack/build/930366c016de49c4b7c26f69b371411a/log/controller/logs/etc/neutron/neutron_conf.txt#1928 In that case tempest tests are failing with NetworkNotFound. For example verfy first test failure in - https://9eed2832462b93d99d63-9a2c0e6b238d9eb37d7a57d0c5074dee.ssl.cf1.rackcdn.com/614484/7/check/tempest-full-enforce-scope-new-defaults/930366c/testr_results.html From the q-svc log (screen-q-svc.txt): below error is coming from ovn side: [None req-1e9ba6eb-84f1-4091-bf3a-862d6e6cb127 admin admin] Mechanism driver 'ovn' failed in create_network_postcommit: neutron_lib.exceptions.NetworkNotFound: Network 75ccd449-9526-4dc2-96c3-4f76ac9dcbe2 could not be found. compete log: https://zuul.opendev.org/t/openstack/build/930366c016de49c4b7c26f69b371411a/log/controller/logs/screen- q-svc.txt#4406 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1996129/+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 1960346] Re: Volume detach failure in devstack-platform-centos-9-stream job
Closing it for nova as it is fixed on the tempest side.
** Changed in: nova
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1960346
Title:
Volume detach failure in devstack-platform-centos-9-stream job
Status in OpenStack Compute (nova):
Invalid
Status in tempest:
Fix Released
Bug description:
devstack-platform-centos-9-stream job is failing 100% with the compute
server rescue test with volume detach error:
traceback-1: {{{
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/common/waiters.py", line 316, in
wait_for_volume_resource_status
raise lib_exc.TimeoutException(message)
tempest.lib.exceptions.TimeoutException: Request timed out
Details: volume 70cedb4b-e74d-4a86-a73d-ba8bce29bc99 failed to reach
available status (current in-use) within the required time (196 s).
}}}
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/common/waiters.py", line 384, in
wait_for_volume_attachment_remove_from_server
raise lib_exc.TimeoutException(message)
tempest.lib.exceptions.TimeoutException: Request timed out
Details: Volume 70cedb4b-e74d-4a86-a73d-ba8bce29bc99 failed to detach from
server cf57d12b-5e37-431e-8c71-4a7149e963ae within the required time (196 s)
from the compute API perspective
https://a886e0e70a23f464643f-7cd608bf14cafb686390b86bc06cde2a.ssl.cf1.rackcdn.com/827576/6/check/devstack-
platform-centos-9-stream/53de74e/testr_results.html
https://zuul.openstack.org/builds?job_name=devstack-platform-centos-9-stream=0
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1960346/+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 1960346] Re: Volume detach failure in devstack-platform-centos-9-stream job
adding tempest for
https://review.opendev.org/q/topic:wait_until_sshable_pingable fixes and
we will see if that fixes the things. if it does then we can remove the
nova from this bug.
** Also affects: tempest
Importance: Undecided
Status: New
** Changed in: tempest
Status: New => Triaged
** Changed in: tempest
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/1960346
Title:
Volume detach failure in devstack-platform-centos-9-stream job
Status in OpenStack Compute (nova):
Triaged
Status in tempest:
Triaged
Bug description:
devstack-platform-centos-9-stream job is failing 100% with the compute
server rescue test with volume detach error:
traceback-1: {{{
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/common/waiters.py", line 316, in
wait_for_volume_resource_status
raise lib_exc.TimeoutException(message)
tempest.lib.exceptions.TimeoutException: Request timed out
Details: volume 70cedb4b-e74d-4a86-a73d-ba8bce29bc99 failed to reach
available status (current in-use) within the required time (196 s).
}}}
Traceback (most recent call last):
File "/opt/stack/tempest/tempest/common/waiters.py", line 384, in
wait_for_volume_attachment_remove_from_server
raise lib_exc.TimeoutException(message)
tempest.lib.exceptions.TimeoutException: Request timed out
Details: Volume 70cedb4b-e74d-4a86-a73d-ba8bce29bc99 failed to detach from
server cf57d12b-5e37-431e-8c71-4a7149e963ae within the required time (196 s)
from the compute API perspective
https://a886e0e70a23f464643f-7cd608bf14cafb686390b86bc06cde2a.ssl.cf1.rackcdn.com/827576/6/check/devstack-
platform-centos-9-stream/53de74e/testr_results.html
https://zuul.openstack.org/builds?job_name=devstack-platform-centos-9-stream=0
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1960346/+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 1957941] Re: test_network_basic_ops failing on centos-8-stream job
nothing to do in devstack side, Marking as invalid. ** Changed in: devstack Status: Incomplete => 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/1957941 Title: test_network_basic_ops failing on centos-8-stream job Status in devstack: Invalid Status in neutron: Invalid Status in tempest: Invalid Bug description: Two test_network_basic_ops tests are failing consistently (since ~ Jan 14th 01 UTC) in centos-8-stream jobs (nova side tempest- integrated-compute-centos-8-stream and tempest tempest-full- py3-centos-8-stream jobs) 1. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic 2. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops Failure: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/logs Only traceback I could find in neutron logs is: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/log/controller/logs/screen- q-svc.txt#32875 To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1957941/+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 1957941] Re: test_network_basic_ops failing on centos-8-stream job
Agree with Lajos, marked invalid for neutron ** Also affects: devstack Importance: Undecided Status: New ** Changed in: devstack Status: New => In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1957941 Title: test_network_basic_ops failing on centos-8-stream job Status in devstack: In Progress Status in neutron: Invalid Status in tempest: Invalid Bug description: Two test_network_basic_ops tests are failing consistently (since ~ Jan 14th 01 UTC) in centos-8-stream jobs (nova side tempest- integrated-compute-centos-8-stream and tempest tempest-full- py3-centos-8-stream jobs) 1. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic 2. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops Failure: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/logs Only traceback I could find in neutron logs is: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/log/controller/logs/screen- q-svc.txt#32875 To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1957941/+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 1957941] Re: test_network_basic_ops failing on centos-8-stream job
yeah, jobs are made voting also now and working fine https://review.opendev.org/c/openstack/tempest/+/824962 ** Changed in: neutron Status: Triaged => 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/1957941 Title: test_network_basic_ops failing on centos-8-stream job Status in devstack: In Progress Status in neutron: Invalid Status in tempest: Invalid Bug description: Two test_network_basic_ops tests are failing consistently (since ~ Jan 14th 01 UTC) in centos-8-stream jobs (nova side tempest- integrated-compute-centos-8-stream and tempest tempest-full- py3-centos-8-stream jobs) 1. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic 2. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops Failure: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/logs Only traceback I could find in neutron logs is: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/log/controller/logs/screen- q-svc.txt#32875 To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1957941/+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 1957941] Re: test_network_basic_ops failing on centos-8-stream job
Thanks yatin. Marking invalid for tempest as nothing to do in Tempest. ** Changed in: tempest Status: New => 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/1957941 Title: test_network_basic_ops failing on centos-8-stream job Status in neutron: Triaged Status in tempest: Invalid Bug description: Two test_network_basic_ops tests are failing consistently (since ~ Jan 14th 01 UTC) in centos-8-stream jobs (nova side tempest- integrated-compute-centos-8-stream and tempest tempest-full- py3-centos-8-stream jobs) 1. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic 2. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops Failure: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/logs Only traceback I could find in neutron logs is: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/log/controller/logs/screen- q-svc.txt#32875 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1957941/+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 1957941] [NEW] test_network_basic_ops failing on centos-8-stream job
Public bug reported: Two test_network_basic_ops tests are failing consistently (since ~ Jan 14th 01 UTC) in centos-8-stream jobs (nova side tempest-integrated- compute-centos-8-stream and tempest tempest-full-py3-centos-8-stream jobs) 1. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic 2. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops Failure: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/logs Only traceback I could find in neutron logs is: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/log/controller/logs/screen- q-svc.txt#32875 ** Affects: neutron Importance: Undecided Status: New ** Affects: tempest Importance: Undecided Status: New ** 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/1957941 Title: test_network_basic_ops failing on centos-8-stream job Status in neutron: New Status in tempest: New Bug description: Two test_network_basic_ops tests are failing consistently (since ~ Jan 14th 01 UTC) in centos-8-stream jobs (nova side tempest- integrated-compute-centos-8-stream and tempest tempest-full- py3-centos-8-stream jobs) 1. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_hotplug_nic 2. tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_network_basic_ops Failure: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/logs Only traceback I could find in neutron logs is: https://zuul.opendev.org/t/openstack/build/e0db6a9a7ba04e66b0781ba7d259357d/log/controller/logs/screen- q-svc.txt#32875 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1957941/+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 1945358] Re: nova-ceph-multistore job is broken on stable branches
Issue is in job variant match in devstack-ceph-plugin fixing in https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/811478 ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1945358 Title: nova-ceph-multistore job is broken on stable branches Status in devstack-plugin-ceph: In Progress Status in OpenStack Compute (nova): Invalid Bug description: nova-ceph-multistore is broken on stable branches: + lib/cinder_backends/ceph:configure_cinder_backend_ceph:56 : is_service_enabled c-bak + functions-common:is_service_enabled:1966 : return 0 + lib/cinder_backends/ceph:configure_cinder_backend_ceph:57 : sudo ceph -c /etc/ceph/ceph.conf osd pool create backups 8 8 pool 'backups' created + lib/cinder_backends/ceph:configure_cinder_backend_ceph:58 : '[' False = False ']' + lib/cinder_backends/ceph:configure_cinder_backend_ceph:60 : sudo ceph -c /etc/ceph/ceph.conf osd pool set backups size 1 Error EPERM: configuring pool size as 1 is disabled by default. https://zuul.opendev.org/t/openstack/build/bc088154e50440fe9a2cacf52426748a more discussion in https://review.opendev.org/c/openstack/devstack/+/811399/2 To manage notifications about this bug go to: https://bugs.launchpad.net/devstack-plugin-ceph/+bug/1945358/+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 1945358] Re: nova-ceph-multistore job is broken on stable branches
** Also affects: devstack-plugin-ceph 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/1945358 Title: nova-ceph-multistore job is broken on stable branches Status in devstack-plugin-ceph: In Progress Status in OpenStack Compute (nova): Invalid Bug description: nova-ceph-multistore is broken on stable branches: + lib/cinder_backends/ceph:configure_cinder_backend_ceph:56 : is_service_enabled c-bak + functions-common:is_service_enabled:1966 : return 0 + lib/cinder_backends/ceph:configure_cinder_backend_ceph:57 : sudo ceph -c /etc/ceph/ceph.conf osd pool create backups 8 8 pool 'backups' created + lib/cinder_backends/ceph:configure_cinder_backend_ceph:58 : '[' False = False ']' + lib/cinder_backends/ceph:configure_cinder_backend_ceph:60 : sudo ceph -c /etc/ceph/ceph.conf osd pool set backups size 1 Error EPERM: configuring pool size as 1 is disabled by default. https://zuul.opendev.org/t/openstack/build/bc088154e50440fe9a2cacf52426748a more discussion in https://review.opendev.org/c/openstack/devstack/+/811399/2 To manage notifications about this bug go to: https://bugs.launchpad.net/devstack-plugin-ceph/+bug/1945358/+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 1945358] [NEW] nova-ceph-multistore job is broken on stable branches
Public bug reported: nova-ceph-multistore is broken on stable branches: + lib/cinder_backends/ceph:configure_cinder_backend_ceph:56 : is_service_enabled c-bak + functions-common:is_service_enabled:1966 : return 0 + lib/cinder_backends/ceph:configure_cinder_backend_ceph:57 : sudo ceph -c /etc/ceph/ceph.conf osd pool create backups 8 8 pool 'backups' created + lib/cinder_backends/ceph:configure_cinder_backend_ceph:58 : '[' False = False ']' + lib/cinder_backends/ceph:configure_cinder_backend_ceph:60 : sudo ceph -c /etc/ceph/ceph.conf osd pool set backups size 1 Error EPERM: configuring pool size as 1 is disabled by default. https://zuul.opendev.org/t/openstack/build/bc088154e50440fe9a2cacf52426748a more discussion in https://review.opendev.org/c/openstack/devstack/+/811399/2 ** Affects: nova Importance: Undecided Status: New ** Tags: gate-failure ** Tags added: gate-failure -- 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/1945358 Title: nova-ceph-multistore job is broken on stable branches Status in OpenStack Compute (nova): New Bug description: nova-ceph-multistore is broken on stable branches: + lib/cinder_backends/ceph:configure_cinder_backend_ceph:56 : is_service_enabled c-bak + functions-common:is_service_enabled:1966 : return 0 + lib/cinder_backends/ceph:configure_cinder_backend_ceph:57 : sudo ceph -c /etc/ceph/ceph.conf osd pool create backups 8 8 pool 'backups' created + lib/cinder_backends/ceph:configure_cinder_backend_ceph:58 : '[' False = False ']' + lib/cinder_backends/ceph:configure_cinder_backend_ceph:60 : sudo ceph -c /etc/ceph/ceph.conf osd pool set backups size 1 Error EPERM: configuring pool size as 1 is disabled by default. https://zuul.opendev.org/t/openstack/build/bc088154e50440fe9a2cacf52426748a more discussion in https://review.opendev.org/c/openstack/devstack/+/811399/2 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1945358/+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 1939350] Re: Keystone protection tests are broken
reverted the devstack change fixed this https://review.opendev.org/c/openstack/devstack/+/804025 ** Also affects: devstack Importance: Undecided Status: New ** Changed in: devstack Status: New => Fix Released -- 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/1939350 Title: Keystone protection tests are broken Status in devstack: Fix Released Status in OpenStack Identity (keystone): Triaged Bug description: The keystone functional protection tests that use tempest are failing during Neutron setup: + functions-common:is_service_enabled:1965 : return 1 + functions-common:run_process:1575: time_stop run_process + functions-common:time_stop:2309 : local name + functions-common:time_stop:2310 : local end_time + functions-common:time_stop:2311 : local elapsed_time + functions-common:time_stop:2312 : local total + functions-common:time_stop:2313 : local start_time + functions-common:time_stop:2315 : name=run_process + functions-common:time_stop:2316 : start_time=1628535788991 + functions-common:time_stop:2318 : [[ -z 1628535788991 ]] ++ functions-common:time_stop:2321 : date +%s%3N + functions-common:time_stop:2321 : end_time=1628535789042 + functions-common:time_stop:2322 : elapsed_time=51 + functions-common:time_stop:2323 : total=5353 + functions-common:time_stop:2325 : _TIME_START[$name]= + functions-common:time_stop:2326 : _TIME_TOTAL[$name]=5404 + ./stack.sh:main:1297 : is_service_enabled q-svc + functions-common:is_service_enabled:1965 : return 0 + ./stack.sh:main:1297 : [[ True == \T\r\u\e ]] + ./stack.sh:main:1298 : echo_summary 'Creating initial neutron network elements' + ./stack.sh:echo_summary:426 : [[ -t 3 ]] + ./stack.sh:echo_summary:432 : echo -e Creating initial neutron network elements + ./stack.sh:main:1301 : type -p neutron_plugin_create_initial_networks + ./stack.sh:main:1304 : 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 : oscwrap project list ++ lib/neutron_plugins/services/l3:create_neutron_initial_network:165 : grep ' demo ' ++ 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 and /usr/lib/python3/dist-packages/secretstorage/dhcrypto.py:15: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead from cryptography.utils import int_from_bytes /usr/lib/python3/dist-packages/secretstorage/util.py:19: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead from cryptography.utils import int_from_bytes You are not authorized to perform the requested action: identity:get_service. (HTTP 403) (Request-ID: req-1fcb0513-4511-48cf-ac80-34c241ddb211) ++functions-common:oscwrap:2349 return 1 +lib/glance:configure_glance_quotas:298iniset /etc/glance/glance-api.conf oslo_limit endpoint_id +lib/glance:configure_glance_quotas:302openstack role add --user glance --user-domain Default --system all reader /usr/lib/python3/dist-packages/secretstorage/dhcrypto.py:15: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead from cryptography.utils import int_from_bytes /usr/lib/python3/dist-packages/secretstorage/util.py:19: CryptographyDeprecationWarning: int_from_bytes is deprecated, use int.from_bytes instead from cryptography.utils import int_from_bytes You are not authorized to perform the requested action: identity:list_roles. (HTTP 403) (Request-ID: req-cab7850c-d24b-4bc7-9068-9153f2af0955) [1191190 Async create_glance_accounts:1239951]: finished create_glance_accounts with result 1 in 23 seconds There appears to be 403s when using keystone tokens to setup things in devstack, so the tests don't even run. I was able to reproduce this locally using: DEVSTACK_PARALLEL=True KEYSTONE_ENFORCE_SCOPE=True enable_plugin keystone
[Yahoo-eng-team] [Bug 1938093] [NEW] Inconsistent return code for "Feature not implemented' API
Public bug reported: There is inconsistency on return code nova API return for "Feature not implemented'. Current return code are 400, 409, and 403. - 400 case: Example: Multiattach Swap Volume Not Supported: https://github.com/openstack/nova/blob/0c64f4c3eae8e2654ec11f60682c0fa5eda30c1a/nova/exception.py#L295 https://github.com/openstack/nova/blob/788035add9b32fa841389d906a0e307c231456ba/nova/api/openstack/compute/volumes.py#L429 - 403 case: Cyborg integration. https://github.com/openstack/nova/blob/0c64f4c3eae8e2654ec11f60682c0fa5eda30c1a/nova/exception.py#L158 https://github.com/openstack/nova/blob/0e7cd9d1a95a30455e3c91916ece590454235e0e/nova/api/openstack/compute/suspend_server.py#L47 - 409 case: Example: Operation Not Supported For SEV , Operation Not Supported For VTPM https://github.com/openstack/nova/blob/0c64f4c3eae8e2654ec11f60682c0fa5eda30c1a/nova/exception.py#L528-L537 In xena PTG, we agreed to fix this by returning 400 in all cases and backport the fix. L446: https://etherpad.opendev.org/p/nova-xena-ptg ** Affects: nova Importance: Undecided Assignee: Ghanshyam Mann (ghanshyammann) Status: Triaged ** Tags: api ** Changed in: nova Status: New => Triaged ** Changed in: nova Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Tags added: 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/1938093 Title: Inconsistent return code for "Feature not implemented' API Status in OpenStack Compute (nova): Triaged Bug description: There is inconsistency on return code nova API return for "Feature not implemented'. Current return code are 400, 409, and 403. - 400 case: Example: Multiattach Swap Volume Not Supported: https://github.com/openstack/nova/blob/0c64f4c3eae8e2654ec11f60682c0fa5eda30c1a/nova/exception.py#L295 https://github.com/openstack/nova/blob/788035add9b32fa841389d906a0e307c231456ba/nova/api/openstack/compute/volumes.py#L429 - 403 case: Cyborg integration. https://github.com/openstack/nova/blob/0c64f4c3eae8e2654ec11f60682c0fa5eda30c1a/nova/exception.py#L158 https://github.com/openstack/nova/blob/0e7cd9d1a95a30455e3c91916ece590454235e0e/nova/api/openstack/compute/suspend_server.py#L47 - 409 case: Example: Operation Not Supported For SEV , Operation Not Supported For VTPM https://github.com/openstack/nova/blob/0c64f4c3eae8e2654ec11f60682c0fa5eda30c1a/nova/exception.py#L528-L537 In xena PTG, we agreed to fix this by returning 400 in all cases and backport the fix. L446: https://etherpad.opendev.org/p/nova-xena-ptg To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1938093/+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 1934478] Re: Invalid aliases in nova.policy
Yes, that is expected behaviour actually. Expected I mean until we remove the legacy policy rules where the reader is nothing but the owner. We have not removed the legacy policy support yet and they are still present as deprecated rule - https://github.com/openstack/nova/blob/e7a7fd51d12d045ff134d55a4a1749c1feee0386/nova/policies/base.py#L127 This means, the old tokens still be able to pass the policy check and create the server. This is with the default policy in code which is your 2nd step. Project reader in legacy policy is nothing but an owner of the project because in legacy policy there is no differentiation between the reader or member role in Nova. so any role in the project is the owner of the resource and that project so they can create a server. This is how we kept this policy migration as backward compatible. Onew you override these policies as you did in step 3 then it removes the legacy policy support and that is why the reader will not be able to create a server. Once we remove the legacy policy support, then new reader role will not be able to create server on new RBAC. I hope I clarified the use case. If not please feel free to reopen it, until now I am marking as invalid because that is behaving as expected. ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1934478 Title: Invalid aliases in nova.policy Status in OpenStack Compute (nova): Invalid Bug description: Description === As of the Rocky release, keystone provides three roles called admin, member, and reader by default. Nova has incorporated those available roles into default policies in Victora version of OpenStack. Servers , howver, can still be created by user who has only reader role in Victoria version. The ambiguos thing is servers cannot be created when I write the default aliases in the policy.yaml of nova. Steps to reproduce == 1. Assign the reader role to the user, for example: openstack role add --user alice --project acme reader 2. Create a server in acme project with user alice openstack --os-username= --os-user-domain-name= --os-password= --os-project-name= --os-project-domain-name= server create --network --flavor --image server_name 3. Add these default aliases to policy.yaml "context_is_admin": "role:admin" "admin_or_owner": "is_admin:True or project_id:%(project_id)s" "admin_api": "is_admin:True" "system_admin_api": "role:admin and system_scope:all" "system_reader_api": "role:reader and system_scope:all" "project_admin_api": "role:admin and project_id:%(project_id)s" "project_member_api": "role:member and project_id:%(project_id)s" "project_reader_api": "role:reader and project_id:%(project_id)s" "system_admin_or_owner": "rule:system_admin_api or rule:project_member_api" "system_or_project_reader": "rule:system_reader_api or rule:project_reader_api" 4. repeat the 3 step Expected result === both the 2 and 4 step cannot create servers Actual result = the 2 step can create servers successfully To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1934478/+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 1913718] Re: rally ci job is unstable - port list takes very long time
** Also affects: oslo.policy 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/1913718 Title: rally ci job is unstable - port list takes very long time Status in neutron: Confirmed Status in oslo.policy: New Bug description: Example of failure https://25ba0cd8b717ae4bad76-16713fdfca2d55e13bffb4aa24c202fc.ssl.cf5.rackcdn.com/772255/5/check/neutron-rally-task/9009341/results/report.html But it happens very often since 27.01. It is probably related to some patches from secure-rbac BP: https://review.opendev.org/q/project:openstack/neutron+status:merged+topic:secure-rbac To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1913718/+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 1844568] Re: [compute] "create_test_server" if networks is undefined and more than one network is present
marking invalid from nova side as no fix needed on nova side for this.
** Changed in: nova
Status: Triaged => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1844568
Title:
[compute] "create_test_server" if networks is undefined and more than
one network is present
Status in OpenStack Compute (nova):
Invalid
Status in tempest:
In Progress
Bug description:
This problem was detected in "ServersNegativeTestJSON" [1]. When a
server is created ("cls.create_test_server"), if a network is not
defined but several networks are present in this project, Nova raises
the exception "NetworkAmbiguous", a seen in this log snippet:
Sep 13 23:44:15.520980 ubuntu-bionic-limestone-regionone-0011283625
devstack@n-api.service[27339]: DEBUG nova.network.neutronv2.api [None
req-c95ecec2-8d10-4984-8ba9-b608161dd645
tempest-ServersNegativeTestJSON-445859222
tempest-ServersNegativeTestJSON-445859222] validate_networks() for None
{{(pid=27340) validate_networks
/opt/stack/nova/nova/network/neutronv2/api.py:2251}}
Sep 13 23:44:15.754945 ubuntu-bionic-limestone-regionone-0011283625
devstack@n-api.service[27339]: INFO nova.api.openstack.wsgi [None
req-c95ecec2-8d10-4984-8ba9-b608161dd645
tempest-ServersNegativeTestJSON-445859222
tempest-ServersNegativeTestJSON-445859222] HTTP exception thrown: Multiple
possible networks found, use a Network ID to be more specific.
We can see that the network information provided to the server creation is
empty but Nova tries to assign a default single network for this server.
However Nova does not assign this default network because several networks are
present for this project ID. In this case, the server creation should be
specific passing the network information.
[1]https://58a87e825b9766115d07-cec36eea8e90c9127fc5a72b798cfeab.ssl.cf2.rackcdn.com/670177/9/check/networking-ovn-tempest-dsvm-ovs-release/b58638a/testr_results.html.gz
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1844568/+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 1904250] [NEW] Default value of config options are incorrect in sample config file
Public bug reported: There are multiple places where nova set the new default value for other (than nova) namespace config option for example oslo lib config options. That is done via oslo APO set_defaults, like - https://github.com/openstack/nova/blob/20572809f2d8fefd72a7a059c4e82462a0d66262/nova/config.py#L62 - https://github.com/openstack/nova/blob/20572809f2d8fefd72a7a059c4e82462a0d66262/nova/policy.py#L48 and these defaults are reflected in code also which is all good and working as expected. But when config sample file is generated via oslo- config-generator tool (tox -egenconfig) then these defaults which are set by Nova are not reflected and this tool take the raw defaults. You can see this issue by generating the new config sample and check what are the defaults for [control_exchange] or [oslo_policy].policy_file To solve this issue oslo config provide a option to add hook to reflect the new default in onfig generator - https://docs.openstack.org/oslo.config/latest/cli/generator.html #modifying-defaults-from-other-namespaces We already doing it for middleware cors option - https://github.com/openstack/nova/blob/20572809f2d8fefd72a7a059c4e82462a0d66262/setup.cfg#L41 Whenever we set default value for non-nova namespace config we need to add those in this hook too so that config sample file are generated with correct defaults. ** 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/1904250 Title: Default value of config options are incorrect in sample config file Status in OpenStack Compute (nova): New Bug description: There are multiple places where nova set the new default value for other (than nova) namespace config option for example oslo lib config options. That is done via oslo APO set_defaults, like - https://github.com/openstack/nova/blob/20572809f2d8fefd72a7a059c4e82462a0d66262/nova/config.py#L62 - https://github.com/openstack/nova/blob/20572809f2d8fefd72a7a059c4e82462a0d66262/nova/policy.py#L48 and these defaults are reflected in code also which is all good and working as expected. But when config sample file is generated via oslo-config-generator tool (tox -egenconfig) then these defaults which are set by Nova are not reflected and this tool take the raw defaults. You can see this issue by generating the new config sample and check what are the defaults for [control_exchange] or [oslo_policy].policy_file To solve this issue oslo config provide a option to add hook to reflect the new default in onfig generator - https://docs.openstack.org/oslo.config/latest/cli/generator.html #modifying-defaults-from-other-namespaces We already doing it for middleware cors option - https://github.com/openstack/nova/blob/20572809f2d8fefd72a7a059c4e82462a0d66262/setup.cfg#L41 Whenever we set default value for non-nova namespace config we need to add those in this hook too so that config sample file are generated with correct defaults. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1904250/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Changed in: python-glanceclient Status: New => Fix Released ** Changed in: castellan Status: In Progress => Fix Released ** Changed in: ec2-api Status: In Progress => Fix Released ** Changed in: os-win Status: New => Fix Released ** Changed in: oslo.messaging Status: In Progress => Fix Released ** Changed in: oslo.policy Status: In Progress => Fix Released ** Changed in: python-senlinclient Status: New => Fix Released ** Changed in: python-troveclient Status: New => Fix Released ** Changed in: python-watcherclient Status: New => Fix Released ** Changed in: watcher Status: New => Fix Released ** Changed in: taskflow Status: New => Fix Released ** Changed in: solum Status: New => Fix Released ** Changed in: solum Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) -- 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: Fix Released Status in ec2-api: Fix Released Status in futurist: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in kolla: Fix Released Status in kolla-ansible: Fix Released Status in OpenStack Shared File Systems Service (Manila): Fix Committed Status in manila-ui: Fix Released Status in masakari: Fix Released Status in masakari victoria series: Fix Released Status in OpenStack Compute (nova): Fix Released Status in os-win: Fix Released Status in oslo.messaging: Fix Released Status in oslo.policy: Fix Released Status in oslo.privsep: Fix Released Status in oslo.reports: Fix Released Status in oslo.vmware: Fix Released Status in Glance Client: Fix Released Status in python-keystoneclient: Fix Committed Status in python-manilaclient: Fix Released Status in python-novaclient: Fix Released Status in python-senlinclient: Fix Released Status in python-troveclient: Fix Released Status in python-watcherclient: Fix Released Status in Solum: Fix Released Status in tacker: Fix Released Status in taskflow: Fix Released Status in tripleo-validations: New Status in watcher: Fix Released Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1885825] Re: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal
** Changed in: coverage2sql Status: New => Fix Released ** Changed in: zaqar Status: New => Fix Released ** Changed in: tacker Status: New => Fix Released ** Changed in: coverage2sql Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Changed in: tacker Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Changed in: zaqar Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) -- 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/1885825 Title: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal Status in coverage2sql: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Compute (nova): Fix Released Status in tacker: Fix Released Status in zaqar: Fix Released Bug description: Ubuntu Focal (20.04) has mysql 8.0 and with mysql 8.0 there is no implicit user creation with GRANT syntax. In Ubuntu Bionic (18.04) mysql 5.7 version used to create the user implicitly when using using the GRANT. But starting with mysql 8.0, we need to create the user explicitly before using the GRANT command. Nova unit and functional tests job using tools/test-setup.sh script start failing when running on Ubuntu Focal https://zuul.opendev.org/t/openstack/build/8b0f4fcc21854655a638c413b6fe1a91 + sudo -H mysql -u root -pinsecure_slave -h localhost -e ' DELETE FROM mysql.user WHERE User='\'''\''; FLUSH PRIVILEGES; GRANT ALL PRIVILEGES ON *.* TO '\''openstack_citest'\''@'\''%'\'' identified by '\''openstack_citest'\'' WITH GRANT OPTION;' mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1064 (42000) at line 4: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by 'openstack_citest' WITH GRANT OPTION' at line 2 we need to modify the tools/test-setup.sh to create user first. Below used to work with mysql 5.7 GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' identified by '$DB_PW' WITH GRANT OPTION;" With mysql 8.0 we need to create user first CREATE USER '$DB_USER'@'%' IDENTIFIED BY '$DB_PW'; GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' WITH GRANT OPTION;" To manage notifications about this bug go to: https://bugs.launchpad.net/coverage2sql/+bug/1885825/+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 1897118] Re: nova-compute does not start in devstack-platform-opensuse-15 job due to < 4.0.0 qemu version
adding devstack also as devstack needs to move to opensuse 15.2[1] which has qemu 4.2.0 available also move jobs to run on opensuse 15.2 will fix this. [1]https://github.com/openstack/devstack/blob/5aa38f51b3dd0660a0622aecd65937d3c56eedc2/stack.sh#L224 ** 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 Compute (nova). https://bugs.launchpad.net/bugs/1897118 Title: nova-compute does not start in devstack-platform-opensuse-15 job due to < 4.0.0 qemu version Status in devstack: New Status in OpenStack Compute (nova): New Bug description: Nova bumped minimum qemu version to 4.0.0 [1]. It seem that the devstack-platform-opensuse-15 non-voting job has older qemu version than that. Therefore nova-compute service does not start[2]. [1] https://review.opendev.org/#/c/746981 [2] https://a5f2733c1907b1f26b90-5593d50c131879f6a486eeedbad80e3c.ssl.cf5.rackcdn.com/743800/14/check/devstack-platform-opensuse-15/91eeaf7/controller/logs/screen-n-cpu.txt To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1897118/+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 1875418] Re: Generated policy.json in Ussuri is broken by default
closing it for oslo polocy also as all required work is done under - https://review.opendev.org/#/q/topic:migrate-to-focal- oslo+(status:open+OR+status:merged) ** Changed in: oslo.policy Status: New => Fix Released ** Changed in: oslo.policy Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) -- 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/1875418 Title: Generated policy.json in Ussuri is broken by default Status in OpenStack Compute (nova): Fix Released Status in oslo.policy: Fix Released Bug description: Looks like the generated policy.json is broken by default and can't be used by operators as-is, as it doesn't include the deprecated options which are unfortunately needed for it to work. With the default policy.json as generated by the nova namespace, the admin user can't even do simple things like: - openstack flavor create - openstack hypervisor list and probably many more... To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1875418/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Changed in: oslo.messaging Status: New => In Progress ** Changed in: oslo.policy Status: New => In Progress ** Changed in: oslo.privsep Status: New => Fix Released ** Changed in: oslo.reports Status: New => Fix Released ** Changed in: oslo.vmware Status: New => Fix Released ** Changed in: python-keystoneclient Status: New => Fix Committed ** Changed in: python-novaclient Status: In Progress => Fix Released ** Changed in: futurist Status: New => Fix Released ** Changed in: castellan Status: New => In Progress ** Changed in: manila Status: New => Fix Committed ** Changed in: manila Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) -- 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: In Progress Status in ec2-api: In Progress Status in futurist: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in kolla: Fix Released Status in kolla-ansible: Fix Released Status in OpenStack Shared File Systems Service (Manila): Fix Committed Status in manila-ui: New Status in masakari: In Progress Status in OpenStack Compute (nova): Fix Released Status in os-win: New Status in oslo.messaging: In Progress Status in oslo.policy: In Progress Status in oslo.privsep: Fix Released Status in oslo.reports: Fix Released Status in oslo.vmware: Fix Released Status in Glance Client: New Status in python-keystoneclient: Fix Committed Status in python-manilaclient: Fix Released Status in python-novaclient: Fix Released Status in python-senlinclient: New Status in python-troveclient: New Status in python-watcherclient: New Status in Solum: New Status in tacker: In Progress Status in taskflow: New Status in tripleo-validations: New Status in watcher: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1885825] Re: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal
** 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 Compute (nova). https://bugs.launchpad.net/bugs/1885825 Title: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal Status in coverage2sql: New Status in OpenStack Identity (keystone): New Status in OpenStack Compute (nova): Fix Released Status in tacker: New Status in zaqar: New Bug description: Ubuntu Focal (20.04) has mysql 8.0 and with mysql 8.0 there is no implicit user creation with GRANT syntax. In Ubuntu Bionic (18.04) mysql 5.7 version used to create the user implicitly when using using the GRANT. But starting with mysql 8.0, we need to create the user explicitly before using the GRANT command. Nova unit and functional tests job using tools/test-setup.sh script start failing when running on Ubuntu Focal https://zuul.opendev.org/t/openstack/build/8b0f4fcc21854655a638c413b6fe1a91 + sudo -H mysql -u root -pinsecure_slave -h localhost -e ' DELETE FROM mysql.user WHERE User='\'''\''; FLUSH PRIVILEGES; GRANT ALL PRIVILEGES ON *.* TO '\''openstack_citest'\''@'\''%'\'' identified by '\''openstack_citest'\'' WITH GRANT OPTION;' mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1064 (42000) at line 4: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by 'openstack_citest' WITH GRANT OPTION' at line 2 we need to modify the tools/test-setup.sh to create user first. Below used to work with mysql 5.7 GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' identified by '$DB_PW' WITH GRANT OPTION;" With mysql 8.0 we need to create user first CREATE USER '$DB_USER'@'%' IDENTIFIED BY '$DB_PW'; GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' WITH GRANT OPTION;" To manage notifications about this bug go to: https://bugs.launchpad.net/coverage2sql/+bug/1885825/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** 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 Compute (nova). https://bugs.launchpad.net/bugs/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in futurist: New Status in manila-ui: New Status in masakari: New Status in OpenStack Compute (nova): In Progress Status in os-win: New Status in oslo.messaging: New Status in oslo.policy: New Status in oslo.privsep: New Status in oslo.reports: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Status in python-senlinclient: New Status in python-troveclient: New Status in python-watcherclient: New Status in Solum: New Status in tacker: New Status in taskflow: New Status in watcher: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: python-senlinclient 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in futurist: New Status in manila-ui: New Status in masakari: New Status in OpenStack Compute (nova): In Progress Status in os-win: New Status in oslo.messaging: New Status in oslo.policy: New Status in oslo.privsep: New Status in oslo.reports: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Status in python-senlinclient: New Status in python-troveclient: New Status in python-watcherclient: New Status in Solum: New Status in tacker: New Status in taskflow: New Status in watcher: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: solum 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in futurist: New Status in manila-ui: New Status in masakari: New Status in OpenStack Compute (nova): In Progress Status in os-win: New Status in oslo.messaging: New Status in oslo.policy: New Status in oslo.privsep: New Status in oslo.reports: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Status in python-troveclient: New Status in python-watcherclient: New Status in Solum: New Status in taskflow: New Status in watcher: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: python-troveclient 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in futurist: New Status in manila-ui: New Status in masakari: New Status in OpenStack Compute (nova): In Progress Status in os-win: New Status in oslo.messaging: New Status in oslo.policy: New Status in oslo.privsep: New Status in oslo.reports: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Status in python-troveclient: New Status in python-watcherclient: New Status in Solum: New Status in taskflow: New Status in watcher: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: os-win Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in futurist: New Status in manila-ui: New Status in masakari: New Status in OpenStack Compute (nova): In Progress Status in os-win: New Status in oslo.messaging: New Status in oslo.policy: New Status in oslo.privsep: New Status in oslo.reports: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Status in python-watcherclient: New Status in taskflow: New Status in watcher: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: python-watcherclient Importance: Undecided Status: New ** Also affects: watcher 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in futurist: New Status in manila-ui: New Status in masakari: New Status in OpenStack Compute (nova): In Progress Status in oslo.messaging: New Status in oslo.policy: New Status in oslo.privsep: New Status in oslo.reports: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Status in python-watcherclient: New Status in taskflow: New Status in watcher: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1885825] Re: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal
** 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 OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1885825 Title: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal Status in coverage2sql: New Status in OpenStack Identity (keystone): New Status in OpenStack Compute (nova): Fix Released Status in zaqar: New Bug description: Ubuntu Focal (20.04) has mysql 8.0 and with mysql 8.0 there is no implicit user creation with GRANT syntax. In Ubuntu Bionic (18.04) mysql 5.7 version used to create the user implicitly when using using the GRANT. But starting with mysql 8.0, we need to create the user explicitly before using the GRANT command. Nova unit and functional tests job using tools/test-setup.sh script start failing when running on Ubuntu Focal https://zuul.opendev.org/t/openstack/build/8b0f4fcc21854655a638c413b6fe1a91 + sudo -H mysql -u root -pinsecure_slave -h localhost -e ' DELETE FROM mysql.user WHERE User='\'''\''; FLUSH PRIVILEGES; GRANT ALL PRIVILEGES ON *.* TO '\''openstack_citest'\''@'\''%'\'' identified by '\''openstack_citest'\'' WITH GRANT OPTION;' mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1064 (42000) at line 4: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by 'openstack_citest' WITH GRANT OPTION' at line 2 we need to modify the tools/test-setup.sh to create user first. Below used to work with mysql 5.7 GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' identified by '$DB_PW' WITH GRANT OPTION;" With mysql 8.0 we need to create user first CREATE USER '$DB_USER'@'%' IDENTIFIED BY '$DB_PW'; GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' WITH GRANT OPTION;" To manage notifications about this bug go to: https://bugs.launchpad.net/coverage2sql/+bug/1885825/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: masakari 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in futurist: New Status in manila-ui: New Status in masakari: New Status in OpenStack Compute (nova): In Progress Status in oslo.messaging: New Status in oslo.policy: New Status in oslo.privsep: New Status in oslo.reports: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Status in taskflow: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: futurist 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in futurist: New Status in manila-ui: New Status in OpenStack Compute (nova): In Progress Status in oslo.messaging: New Status in oslo.policy: New Status in oslo.privsep: New Status in oslo.reports: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Status in taskflow: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: oslo.policy Importance: Undecided Status: New ** Also affects: oslo.reports 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in manila-ui: New Status in OpenStack Compute (nova): In Progress Status in oslo.messaging: New Status in oslo.policy: New Status in oslo.privsep: New Status in oslo.reports: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Status in taskflow: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: taskflow Importance: Undecided Status: New ** Changed in: python-glanceclient Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Changed in: castellan Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Changed in: ec2-api Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Changed in: python-keystoneclient Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Changed in: taskflow Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Changed in: python-manilaclient Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Also affects: oslo.vmware Importance: Undecided Status: New ** Also affects: oslo.messaging Importance: Undecided Status: New ** Also affects: oslo.privsep 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in manila-ui: New Status in OpenStack Compute (nova): In Progress Status in oslo.messaging: New Status in oslo.privsep: New Status in oslo.vmware: New Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Status in taskflow: New Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: castellan 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in castellan: New Status in ec2-api: New Status in manila-ui: New Status in OpenStack Compute (nova): In Progress Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/castellan/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in ec2-api: New Status in manila-ui: New Status in OpenStack Compute (nova): In Progress Status in Glance Client: New Status in python-keystoneclient: New Status in python-manilaclient: New Status in python-novaclient: In Progress Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ec2-api/+bug/1886298/+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 1885825] Re: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal
** Also affects: coverage2sql 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/1885825 Title: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal Status in coverage2sql: New Status in OpenStack Identity (keystone): New Status in OpenStack Compute (nova): Fix Released Bug description: Ubuntu Focal (20.04) has mysql 8.0 and with mysql 8.0 there is no implicit user creation with GRANT syntax. In Ubuntu Bionic (18.04) mysql 5.7 version used to create the user implicitly when using using the GRANT. But starting with mysql 8.0, we need to create the user explicitly before using the GRANT command. Nova unit and functional tests job using tools/test-setup.sh script start failing when running on Ubuntu Focal https://zuul.opendev.org/t/openstack/build/8b0f4fcc21854655a638c413b6fe1a91 + sudo -H mysql -u root -pinsecure_slave -h localhost -e ' DELETE FROM mysql.user WHERE User='\'''\''; FLUSH PRIVILEGES; GRANT ALL PRIVILEGES ON *.* TO '\''openstack_citest'\''@'\''%'\'' identified by '\''openstack_citest'\'' WITH GRANT OPTION;' mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1064 (42000) at line 4: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by 'openstack_citest' WITH GRANT OPTION' at line 2 we need to modify the tools/test-setup.sh to create user first. Below used to work with mysql 5.7 GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' identified by '$DB_PW' WITH GRANT OPTION;" With mysql 8.0 we need to create user first CREATE USER '$DB_USER'@'%' IDENTIFIED BY '$DB_PW'; GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' WITH GRANT OPTION;" To manage notifications about this bug go to: https://bugs.launchpad.net/coverage2sql/+bug/1885825/+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 1885825] Re: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal
** 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 Compute (nova). https://bugs.launchpad.net/bugs/1885825 Title: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal Status in OpenStack Identity (keystone): New Status in OpenStack Compute (nova): Fix Released Bug description: Ubuntu Focal (20.04) has mysql 8.0 and with mysql 8.0 there is no implicit user creation with GRANT syntax. In Ubuntu Bionic (18.04) mysql 5.7 version used to create the user implicitly when using using the GRANT. But starting with mysql 8.0, we need to create the user explicitly before using the GRANT command. Nova unit and functional tests job using tools/test-setup.sh script start failing when running on Ubuntu Focal https://zuul.opendev.org/t/openstack/build/8b0f4fcc21854655a638c413b6fe1a91 + sudo -H mysql -u root -pinsecure_slave -h localhost -e ' DELETE FROM mysql.user WHERE User='\'''\''; FLUSH PRIVILEGES; GRANT ALL PRIVILEGES ON *.* TO '\''openstack_citest'\''@'\''%'\'' identified by '\''openstack_citest'\'' WITH GRANT OPTION;' mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1064 (42000) at line 4: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by 'openstack_citest' WITH GRANT OPTION' at line 2 we need to modify the tools/test-setup.sh to create user first. Below used to work with mysql 5.7 GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' identified by '$DB_PW' WITH GRANT OPTION;" With mysql 8.0 we need to create user first CREATE USER '$DB_USER'@'%' IDENTIFIED BY '$DB_PW'; GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' WITH GRANT OPTION;" To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1885825/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: python-keystoneclient 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in manila-ui: New Status in OpenStack Compute (nova): In Progress Status in Glance Client: New Status in python-keystoneclient: New Status in python-novaclient: In Progress Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/manila-ui/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: python-glanceclient 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in manila-ui: New Status in OpenStack Compute (nova): In Progress Status in Glance Client: New Status in python-keystoneclient: New Status in python-novaclient: In Progress Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/manila-ui/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Also affects: manila-ui 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/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in manila-ui: New Status in OpenStack Compute (nova): In Progress Status in python-novaclient: In Progress Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 To manage notifications about this bug go to: https://bugs.launchpad.net/manila-ui/+bug/1886298/+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 1886298] Re: Few of the lower constraints are not compatible with python3.8
** Description changed: - Markupsafe 1.0 fail the lower-constraints job with + lower constraint are being tested with python.6 till now and jobs + running fine. With the migration of testing to ubuntu focal where + python3.8 is default, lower-constraints job started failing due to + multiple issues. - ImportError: cannot import name 'Feature' from 'setuptools' + For example, - - - https://zuul.opendev.org/t/openstack/build/df8ddce0a9c84397bfe3976cf955fcbb/log - /job-output.txt - - Issue is fixed in Markupsafe 1.1.1 + Markupsafe 1.o not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 - We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it - work with latest setuptools. + paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: + https://github.com/paramiko/paramiko/issues/1108 + + greenlet 0.4.15 added wheels for python 3.8: + https://github.com/python-greenlet/greenlet/issues/151 + + numpy 1.19.1 added python 3.8 support and testing: + https://github.com/numpy/numpy/pull/14775 + + paramiko 2.7.1 fixed the compatibility for python3.7 onwards: + https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 + + Similarly there are many dependencies which added the python3.8 support + in their later version. So we need to bump their lower constraints to + compatible version. + + Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos + and found below version bump: + + For Nova: + Markupsafe==1.1.1 + cffi==1.14.0 + greenlet==0.4.15 + PyYAML==3.13 + lxml==4.5.0 + numpy==1.19.0 + psycopg2==2.8 + paramiko==2.7.1 + + For python-novaclient: + Markupsafe==1.1.1 + cffi==1.14.0 + greenlet==0.4.15 + PyYAML==3.13 + + For os-vif: + Markupsafe==1.1.1 + cffi==1.14.0 ** Description changed: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, - Markupsafe 1.o not compatible with new setuptools: + Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed things. I started with nova repos and found below version bump: For Nova: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 lxml==4.5.0 numpy==1.19.0 psycopg2==2.8 paramiko==2.7.1 For python-novaclient: Markupsafe==1.1.1 cffi==1.14.0 greenlet==0.4.15 PyYAML==3.13 For os-vif: Markupsafe==1.1.1 cffi==1.14.0 ** 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 OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1886298 Title: Few of the lower constraints are not compatible with python3.8 Status in OpenStack Compute (nova): In Progress Status in python-novaclient: In Progress Bug description: lower constraint are being tested with python.6 till now and jobs running fine. With the migration of testing to ubuntu focal where python3.8 is default, lower-constraints job started failing due to multiple issues. For example, Markupsafe 1.0 not compatible with new setuptools: - https://github.com/pallets/markupsafe/issues/116 paramiko 2.7.1 fixed the compatiblity for python3.7 onwards: https://github.com/paramiko/paramiko/issues/1108 greenlet 0.4.15 added wheels for python 3.8: https://github.com/python-greenlet/greenlet/issues/151 numpy 1.19.1 added python 3.8 support and testing: https://github.com/numpy/numpy/pull/14775 paramiko 2.7.1 fixed the compatibility for python3.7 onwards: https://github.com/paramiko/paramiko/commit/4753881223e0ff5e3b3be35bb687a18dfec4f672 Similarly there are many dependencies which added the python3.8 support in their later version. So we need to bump their lower constraints to compatible version. Approach to identify the required bump is by running lower-constraint job on Focal and star bumping for the failed
[Yahoo-eng-team] [Bug 1886298] [NEW] Cannot import name "Feature" from "setuptools"
Public bug reported: Markupsafe 1.0 fail the lower-constraints job with ImportError: cannot import name 'Feature' from 'setuptools' - https://zuul.opendev.org/t/openstack/build/df8ddce0a9c84397bfe3976cf955fcbb/log /job-output.txt Issue is fixed in Markupsafe 1.1.1 - https://github.com/pallets/markupsafe/issues/116 We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work with latest setuptools. ** 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/1886298 Title: Cannot import name "Feature" from "setuptools" Status in OpenStack Compute (nova): New Bug description: Markupsafe 1.0 fail the lower-constraints job with ImportError: cannot import name 'Feature' from 'setuptools' - https://zuul.opendev.org/t/openstack/build/df8ddce0a9c84397bfe3976cf955fcbb/log /job-output.txt Issue is fixed in Markupsafe 1.1.1 - https://github.com/pallets/markupsafe/issues/116 We need to bump the lower-constraint for Markupsafe to 1.1.1 to make it work with latest setuptools. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1886298/+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 1885825] [NEW] No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal
Public bug reported: Ubuntu Focal (20.04) has mysql 8.0 and with mysql 8.0 there is no implicit user creation with GRANT syntax. In Ubuntu Bionic (18.04) mysql 5.7 version used to create the user implicitly when using using the GRANT. But starting with mysql 8.0, we need to create the user explicitly before using the GRANT command. Nova unit and functional tests job using tools/test-setup.sh script start failing when running on Ubuntu Focal https://zuul.opendev.org/t/openstack/build/8b0f4fcc21854655a638c413b6fe1a91 + sudo -H mysql -u root -pinsecure_slave -h localhost -e ' DELETE FROM mysql.user WHERE User='\'''\''; FLUSH PRIVILEGES; GRANT ALL PRIVILEGES ON *.* TO '\''openstack_citest'\''@'\''%'\'' identified by '\''openstack_citest'\'' WITH GRANT OPTION;' mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1064 (42000) at line 4: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by 'openstack_citest' WITH GRANT OPTION' at line 2 we need to modify the tools/test-setup.sh to create user first. Below used to work with mysql 5.7 GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' identified by '$DB_PW' WITH GRANT OPTION;" With mysql 8.0 we need to create user first CREATE USER '$DB_USER'@'%' IDENTIFIED BY '$DB_PW'; GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' WITH GRANT OPTION;" ** Affects: nova Importance: Undecided Assignee: Ghanshyam Mann (ghanshyammann) 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/1885825 Title: No implicit user creation with GRANT syntax in MySQL 8.0 Ubuntu Focal Status in OpenStack Compute (nova): In Progress Bug description: Ubuntu Focal (20.04) has mysql 8.0 and with mysql 8.0 there is no implicit user creation with GRANT syntax. In Ubuntu Bionic (18.04) mysql 5.7 version used to create the user implicitly when using using the GRANT. But starting with mysql 8.0, we need to create the user explicitly before using the GRANT command. Nova unit and functional tests job using tools/test-setup.sh script start failing when running on Ubuntu Focal https://zuul.opendev.org/t/openstack/build/8b0f4fcc21854655a638c413b6fe1a91 + sudo -H mysql -u root -pinsecure_slave -h localhost -e ' DELETE FROM mysql.user WHERE User='\'''\''; FLUSH PRIVILEGES; GRANT ALL PRIVILEGES ON *.* TO '\''openstack_citest'\''@'\''%'\'' identified by '\''openstack_citest'\'' WITH GRANT OPTION;' mysql: [Warning] Using a password on the command line interface can be insecure. ERROR 1064 (42000) at line 4: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'identified by 'openstack_citest' WITH GRANT OPTION' at line 2 we need to modify the tools/test-setup.sh to create user first. Below used to work with mysql 5.7 GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' identified by '$DB_PW' WITH GRANT OPTION;" With mysql 8.0 we need to create user first CREATE USER '$DB_USER'@'%' IDENTIFIED BY '$DB_PW'; GRANT ALL PRIVILEGES ON *.* TO '$DB_USER'@'%' WITH GRANT OPTION;" To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1885825/+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 1882521] Re: Failing device detachments on Focal
adding cinder also if something from cinder side during detachment.
** Also affects: cinder
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/1882521
Title:
Failing device detachments on Focal
Status in Cinder:
New
Status in OpenStack Compute (nova):
New
Bug description:
The following tests are failing consistently when deploying devstack
on Focal in the CI, see https://review.opendev.org/734029 for detailed
logs:
tempest.api.compute.servers.test_server_rescue_negative.ServerRescueNegativeTestJSON.test_rescued_vm_detach_volume
tempest.api.compute.volumes.test_attach_volume.AttachVolumeMultiAttachTest.test_resize_server_with_multiattached_volume
tempest.api.compute.servers.test_server_rescue.ServerStableDeviceRescueTest.test_stable_device_rescue_disk_virtio_with_volume_attached
tearDownClass
(tempest.api.compute.servers.test_server_rescue.ServerStableDeviceRescueTest)
Sample extract from nova-compute log:
Jun 08 08:48:24.384559 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
DEBUG oslo.service.loopingcall [-] Exception which is in the suggested list of
exceptions occurred while invoking function:
nova.virt.libvirt.guest.Guest.detach_device_with_retry.._do_wait_and_retry_detach.
{{(pid=82495) _func
/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py:410}}
Jun 08 08:48:24.384862 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
DEBUG oslo.service.loopingcall [-] Cannot retry
nova.virt.libvirt.guest.Guest.detach_device_with_retry.._do_wait_and_retry_detach
upon suggested exception since retry count (7) reached max retry count (7).
{{(pid=82495) _func
/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py:416}}
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall [-] Dynamic interval looping call
'oslo_service.loopingcall.RetryDecorator.__call__.._func' failed:
nova.exception.DeviceDetachFailed: Device detach failed for vdb: Unable to
detach the device from the live config.
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall Traceback (most recent call last):
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall File
"/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py", line 150,
in _run_loop
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall result = func(*self.args, **self.kw)
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall File
"/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py", line 428,
in _func
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall return self._sleep_time
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall File
"/usr/local/lib/python3.8/dist-packages/oslo_utils/excutils.py", line 220, in
__exit__
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall self.force_reraise()
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall File
"/usr/local/lib/python3.8/dist-packages/oslo_utils/excutils.py", line 196, in
force_reraise
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall six.reraise(self.type_, self.value, self.tb)
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall File
"/usr/local/lib/python3.8/dist-packages/six.py", line 703, in reraise
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall raise value
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall File
"/usr/local/lib/python3.8/dist-packages/oslo_service/loopingcall.py", line 407,
in _func
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall result = f(*args, **kwargs)
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall File
"/opt/stack/nova/nova/virt/libvirt/guest.py", line 453, in
_do_wait_and_retry_detach
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall raise exception.DeviceDetachFailed(
Jun 08 08:48:24.388855 ubuntu-focal-rax-dfw-0017012548 nova-compute[82495]:
ERROR oslo.service.loopingcall nova.exception.DeviceDetachFailed: Device detach
failed for vdb: Unable to detach the device
[Yahoo-eng-team] [Bug 1884256] Re: 'tox' not present on devstack based jobs
** Changed in: devstack 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/1884256 Title: 'tox' not present on devstack based jobs Status in devstack: Invalid Status in neutron: Fix Released Bug description: devstack base jobs might be used for running the tox env. Even tempest jobs need tox to be present to run the tempest tests in venv. but devstack base jobs does not make sure tox is present or not using ensure-tox role. Tempest jobs are fine as tox is being explicitly installed by install_tempest - https://opendev.org/openstack/devstack/src/branch/stable/stein/lib/tempest#L691-L708 But any other job not using devstack installing the tempest or devstack jobs used as base job for functional tests started failing on that, Current neutorn functional job failure- - https://zuul.opendev.org/t/openstack/build/59865004855c404ab18f06fc0ec1d005 To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1884256/+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 1884256] Re: 'tox' not present on devstack based jobs
** 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/1884256 Title: 'tox' not present on devstack based jobs Status in devstack: In Progress Status in neutron: In Progress Bug description: devstack base jobs might be used for running the tox env. Even tempest jobs need tox to be present to run the tempest tests in venv. but devstack base jobs does not make sure tox is present or not using ensure-tox role. Tempest jobs are fine as tox is being explicitly installed by install_tempest - https://opendev.org/openstack/devstack/src/branch/stable/stein/lib/tempest#L691-L708 But any other job not using devstack installing the tempest or devstack jobs used as base job for functional tests started failing on that, Current neutorn functional job failure- - https://zuul.opendev.org/t/openstack/build/59865004855c404ab18f06fc0ec1d005 To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1884256/+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 1883200] [NEW] pdf-docs build failing on sphinx 3.1.0
Public bug reported: with the new release of sphinx 3.1.0, nova pdf docs build started failing with "! Dimension too large." error. That started failing since 10th June when the OpenStack requirement added a new constraint for sphinx. Seems like somewhere TeX memory is exhausted during the pdf building. If I am not wrong we are hitting this open sphinx bug[1]. I checked the doc/source/_static/images dimensions first which is what I doubted at the very first place and there is no issue in images. Verified that by tried to build the pdf without images and got the same error. - https://zuul.opendev.org/t/openstack/build/9c3e835ad5ee4842a07d77fdbaa6c97d/log /sphinx-build-pdf.log#7661 I cannot find any related changes in sphinx 3.1.0 also - https://www.sphinx-doc.org/en/master/changes.html - https://github.com/sphinx-doc/sphinx/commits/v3.1.0 [1] https://github.com/sphinx-doc/sphinx/issues/3099 ** 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/1883200 Title: pdf-docs build failing on sphinx 3.1.0 Status in OpenStack Compute (nova): New Bug description: with the new release of sphinx 3.1.0, nova pdf docs build started failing with "! Dimension too large." error. That started failing since 10th June when the OpenStack requirement added a new constraint for sphinx. Seems like somewhere TeX memory is exhausted during the pdf building. If I am not wrong we are hitting this open sphinx bug[1]. I checked the doc/source/_static/images dimensions first which is what I doubted at the very first place and there is no issue in images. Verified that by tried to build the pdf without images and got the same error. - https://zuul.opendev.org/t/openstack/build/9c3e835ad5ee4842a07d77fdbaa6c97d/log /sphinx-build-pdf.log#7661 I cannot find any related changes in sphinx 3.1.0 also - https://www.sphinx-doc.org/en/master/changes.html - https://github.com/sphinx-doc/sphinx/commits/v3.1.0 [1] https://github.com/sphinx-doc/sphinx/issues/3099 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1883200/+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 1875418] Re: Generated policy.json in Ussuri is broken by default
That is correct what you wrote above. But tricky part here is generated policy.json from 'oslopolicy-sample-generator' tool without deprecated rules is right thing or wrong. Because it can be seen as one of the valid usgae for deployer who want to switch to new defaults. The only way for them till ussuri(till we introduced new flag in oslo) is to overwrite the policy file with new default (which is what 'oslopolicy- sample-generator 'generate). If we add arg option in 'oslopolicy-sample-generator ' to add a deprecated rule (say --add-deprecated-rules) that also should not be default and deployer need to change the usage of that tool to pass the new arg. Opinion ? also other challenge is we need to check with Oslo team if that can be done now for ussuri. adding oslo also as an affected project. Also, what we are missing here is this bug actually - https://bugs.launchpad.net/oslo.policy/+bug/1853170 ** Also affects: oslo.policy 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/1875418 Title: Generated policy.json in Ussuri is broken by default Status in OpenStack Compute (nova): In Progress Status in oslo.policy: New Bug description: Looks like the generated policy.json is broken by default and can't be used by operators as-is, as it doesn't include the deprecated options which are unfortunately needed for it to work. With the default policy.json as generated by the nova namespace, the admin user can't even do simple things like: - openstack flavor create - openstack hypervisor list and probably many more... To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1875418/+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 1871327] Re: stable/stein tempest-full job fails with "tempest requires Python '>=3.6' but the running Python is 2.7.17"
** Also affects: devstack Importance: Undecided Status: New ** Changed in: tempest Status: New => Invalid ** Changed in: devstack Status: New => Fix Committed ** Changed in: devstack Importance: Undecided => High ** Changed in: devstack Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1871327 Title: stable/stein tempest-full job fails with "tempest requires Python '>=3.6' but the running Python is 2.7.17" Status in devstack: Fix Committed Status in neutron: Invalid Status in tempest: Invalid Bug description: Only seen in stable/stein, tempest-full (and also non-voting neutron-tempest-dvr-ha-multinode-full) job fails with: Obtaining file:///opt/stack/tempest tempest requires Python '>=3.6' but the running Python is 2.7.17 Example failure on https://review.opendev.org/#/c/717336/2: https://zuul.opendev.org/t/openstack/build/f05569c475f44327bff7b7ec58faef8c https://zuul.opendev.org/t/openstack/build/651ca00e67ab42fd814ec5edad437997 While backport on rocky passed both: https://review.opendev.org/#/c/717337/2 https://zuul.opendev.org/t/openstack/build/c9c0139cda4f45cd825e169765e6854c https://zuul.opendev.org/t/openstack/build/6f318c4897ea4864b7cd2691dc2a36ab and on train: https://review.opendev.org/#/c/717335/2 https://zuul.opendev.org/t/openstack/build/f84209f049f2459eabd453058ad11ccf For neutron-tempest-dvr-ha-multinode-full parent in stein is tempest- multinode-full so it looks like common issue in tempest-full job definition for this branch? To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1871327/+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 1871665] [NEW] servers actions (many) API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: server actions like confirm_resize, reboot etc API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/718348/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/api/openstack/compute/servers.py#L872 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/policies/servers.py#L285 ** Affects: nova Importance: Undecided Assignee: Ghanshyam Mann (ghanshyammann) Status: In Progress ** Tags: policy ** Project changed: neutron => nova ** Tags added: policy -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1871665 Title: servers actions (many) API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): In Progress Bug description: server actions like confirm_resize, reboot etc API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/718348/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/api/openstack/compute/servers.py#L872 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/policies/servers.py#L285 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1871665/+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 1871287] [NEW] server tags API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: server tags API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717425 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/api/openstack/compute/server_tags.py#L88 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/policies/server_tags.py#L27 ** Affects: nova Importance: Undecided Status: New ** Tags: policy ** Tags added: policy -- 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/1871287 Title: server tags API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: server tags API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717425 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/api/openstack/compute/server_tags.py#L88 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/cd16ae25c865f25dbb313976b3d8ef9372db80af/nova/policies/server_tags.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1871287/+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 1870883] [NEW] resume server API policy is allowed for everyone even policy defaults is admin_or_owner Edit
Public bug reported: server resume API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717182/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/api/openstack/compute/suspend_server.py#L56 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/policies/suspend_server.py#L37 ** 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/1870883 Title: resume server API policy is allowed for everyone even policy defaults is admin_or_owner Edit Status in OpenStack Compute (nova): New Bug description: server resume API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717182/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/api/openstack/compute/suspend_server.py#L56 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/policies/suspend_server.py#L37 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1870883/+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 1870881] [NEW] server shelve API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: server shelve API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717182/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/api/openstack/compute/shelve.py#L89 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/policies/shelve.py#L37 ** 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/1870881 Title: server shelve API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: server shelve API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717182/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/api/openstack/compute/shelve.py#L89 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/policies/shelve.py#L37 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1870881/+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 1870872] [NEW] server topology API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: server topology index policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717524/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/api/openstack/compute/server_topology.py#L30 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/policies/server_topology.py#L24 ** 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/1870872 Title: server topology API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: server topology index policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717524/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/api/openstack/compute/server_topology.py#L30 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/e4ac401d1a9d5fba24bc22141b362a5400d9d096/nova/policies/server_topology.py#L24 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1870872/+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 1870488] [NEW] server password API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: server password API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717204 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/e487b05f7e451af4f29699c3b34d9d2cc1b1205a/nova/api/openstack/compute/server_password.py#L34 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/e487b05f7e451af4f29699c3b34d9d2cc1b1205a/nova/policies/server_password.py#L27 ** 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/1870488 Title: server password API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: server password API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717204 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/e487b05f7e451af4f29699c3b34d9d2cc1b1205a/nova/api/openstack/compute/server_password.py#L34 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/e487b05f7e451af4f29699c3b34d9d2cc1b1205a/nova/policies/server_password.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1870488/+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 1870484] [NEW] server metadata API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: server metadata API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717182/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/e487b05f7e451af4f29699c3b34d9d2cc1b1205a/nova/api/openstack/compute/server_metadata.py#L123 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/e487b05f7e451af4f29699c3b34d9d2cc1b1205a/nova/policies/server_metadata.py#L27 ** Affects: nova Importance: Undecided Status: New ** Tags: policy ** Tags added: policy -- 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/1870484 Title: server metadata API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: server metadata API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/717182/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/e487b05f7e451af4f29699c3b34d9d2cc1b1205a/nova/api/openstack/compute/server_metadata.py#L123 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/e487b05f7e451af4f29699c3b34d9d2cc1b1205a/nova/policies/server_metadata.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1870484/+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 1870226] [NEW] os-security-groups API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: os-security-groups restore server API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/716779/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/7b51647f17c88c7c1ae321c59ab8a98c586d4b67/nova/api/openstack/compute/security_groups.py#L427 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/7b51647f17c88c7c1ae321c59ab8a98c586d4b67/nova/policies/security_groups.py#L27 ** 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/1870226 Title: os-security-groups API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: os-security-groups restore server API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/716779/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/7b51647f17c88c7c1ae321c59ab8a98c586d4b67/nova/api/openstack/compute/security_groups.py#L427 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/7b51647f17c88c7c1ae321c59ab8a98c586d4b67/nova/policies/security_groups.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1870226/+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 1869841] [NEW] unpause server API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: unpause server API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/716161//1 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/eb6bd04e4c27c70b5239dbe7c17607b37f4e87dd/nova/api/openstack/compute/pause_server.py#L58 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/eb6bd04e4c27c70b5239dbe7c17607b37f4e87dd/nova/policies/pause_server.py#L38 ** Affects: nova Importance: Undecided Status: New ** Tags: policy ** Tags added: policy -- 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/1869841 Title: unpause server API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: unpause server API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/716161//1 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/eb6bd04e4c27c70b5239dbe7c17607b37f4e87dd/nova/api/openstack/compute/pause_server.py#L58 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/eb6bd04e4c27c70b5239dbe7c17607b37f4e87dd/nova/policies/pause_server.py#L38 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1869841/+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 1869791] [NEW] unlock server API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: unlock server API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/716057/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/a534ccc5a7dbe687277d9233883f500ec635fe04/nova/api/openstack/compute/lock_server.py#L46 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/7b51647f17c88c7c1ae321c59ab8a98c586d4b67/nova/policies/lock_server.py#L38 ** Affects: nova Importance: Undecided Status: New ** Tags: policy ** Tags added: policy -- 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/1869791 Title: unlock server API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: unlock server API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/716057/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/a534ccc5a7dbe687277d9233883f500ec635fe04/nova/api/openstack/compute/lock_server.py#L46 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/7b51647f17c88c7c1ae321c59ab8a98c586d4b67/nova/policies/lock_server.py#L38 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1869791/+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 1869543] [NEW] GET limits API policy is allowed for everyone but policy defaults is admin_or_owner
Public bug reported: limits API policy is allowed for everyone but policy is default to admin_or_owner[1]. This is because API does not pass the project_id in policy target so that oslo policy can decide the ownership. https://github.com/openstack/nova/blob/403fc671a6877889d6fb70360e002d9b22b98fc9/nova/api/openstack/compute/limits.py#L77 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 There is no owner things in limits and every projects can get its own limits. We need to make default to RULE_ANY which means allowed to everyone. [1] - https://github.com/openstack/nova/blob/403fc671a6877889d6fb70360e002d9b22b98fc9/nova/policies/limits.py#L27 ** Affects: nova Importance: Undecided Status: New ** Tags: policy ** Tags added: policy -- 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/1869543 Title: GET limits API policy is allowed for everyone but policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: limits API policy is allowed for everyone but policy is default to admin_or_owner[1]. This is because API does not pass the project_id in policy target so that oslo policy can decide the ownership. https://github.com/openstack/nova/blob/403fc671a6877889d6fb70360e002d9b22b98fc9/nova/api/openstack/compute/limits.py#L77 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 There is no owner things in limits and every projects can get its own limits. We need to make default to RULE_ANY which means allowed to everyone. [1] - https://github.com/openstack/nova/blob/403fc671a6877889d6fb70360e002d9b22b98fc9/nova/policies/limits.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1869543/+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 1869396] [NEW] os-ips API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: os-ips API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/715477/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/api/openstack/compute/ips.py#L41 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/eaf08c0b7b8250408e5d10c6471f2e3155cc0edb/nova/policies/ips.py#L27 ** 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/1869396 Title: os-ips API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: os-ips API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/715477/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/api/openstack/compute/ips.py#L41 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/eaf08c0b7b8250408e5d10c6471f2e3155cc0edb/nova/policies/ips.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1869396/+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 1867840] [NEW] os-flavor-access API policy should be admin only
Public bug reported: os-flavor-access API policy is default to admin_or_owner[1] but API is allowed for everyone. This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/api/openstack/compute/flavor_access.py#L45 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 I do not think there is owner things for flavor as multiple tenant can be added to access the flavor. I think we should default this policy to admin only and admin only should be able to list all the tenants who has access to specific flavor. [1] - https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/policies/flavor_access.py#L49 ** Affects: nova Importance: Undecided Assignee: Ghanshyam Mann (ghanshyammann) Status: New ** Changed in: nova Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) -- 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/1867840 Title: os-flavor-access API policy should be admin only Status in OpenStack Compute (nova): New Bug description: os-flavor-access API policy is default to admin_or_owner[1] but API is allowed for everyone. This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/api/openstack/compute/flavor_access.py#L45 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 I do not think there is owner things for flavor as multiple tenant can be added to access the flavor. I think we should default this policy to admin only and admin only should be able to list all the tenants who has access to specific flavor. [1] - https://github.com/openstack/nova/blob/96f6622316993fb41f4c5f37852d4c879c9716a5/nova/policies/flavor_access.py#L49 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1867840/+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 1865117] Re: fatal=False in context.can() impact the policy-defaults-refresh to get expect tests results
as discussed on review, we should not change the fetal=false, instead we can adjust the test to verify the things. In this case, we should use the response to verify the policy enforcement not 403. ** Changed in: nova Status: In Progress => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1865117 Title: fatal=False in context.can() impact the policy-defaults-refresh to get expect tests results Status in OpenStack Compute (nova): Invalid Bug description: While we do policy-defaults-refresh feature of os-instance-actions show API [1]. We should test the authorized contexts and the unauthorized contexts, and check the PolicyNotAuthorized [2]. If we set fatal=False in context.can(), we will not get the PolicyNotAuthorized exception (e.g.[1]) [3], so we should adjust the judgment strategy when context.can() is used as a condition. [1]https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/instance_actions.py#L161 [2]https://github.com/openstack/nova/blob/master/nova/tests/unit/policies/base.py#L96-L101 [3]https://review.opendev.org/#/c/70/2/nova/tests/unit/policies/test_instance_actions.py@131 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1865117/+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 1863009] [NEW] os-deferred-delete restore server API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: os-deferred-delete restore server API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/707455/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/api/openstack/compute/deferred_delete.py#L38 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/policies/deferred_delete.py#L27 ** 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/1863009 Title: os-deferred-delete restore server API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: os-deferred-delete restore server API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/707455/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/api/openstack/compute/deferred_delete.py#L38 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/policies/deferred_delete.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1863009/+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 1862561] [NEW] os-create-backup API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: os-create-backup API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/706726/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/api/openstack/compute/create_backup.py#L50 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/policies/create_backup.py#L27 ** 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/1862561 Title: os-create-backup API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: os-create-backup API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/706726/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/api/openstack/compute/create_backup.py#L50 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/policies/create_backup.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1862561/+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 1862558] [NEW] os-console-output API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: os-console-output API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/706724/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/api/openstack/compute/console_output.py#L41 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/policies/console_output.py#L27 ** 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/1862558 Title: os-console-output API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: os-console-output API policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/706724/ This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/api/openstack/compute/console_output.py#L41 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/policies/console_output.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1862558/+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 1862484] [NEW] GET os-availability-zone API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: os-availability-zone API policy is default to admin_or_owner[1] but API is allowed for everyone. This is because API does not pass the project_id in policy target so that oslo policy can decide the ownership. https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/api/openstack/compute/availability_zone.py#L111 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 We need to default the GET /os-availability-zone policy same as GET details /os-availability-zone which is admin. [1] - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/policies/availability_zone.py#L27 ** 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/1862484 Title: GET os-availability-zone API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: os-availability-zone API policy is default to admin_or_owner[1] but API is allowed for everyone. This is because API does not pass the project_id in policy target so that oslo policy can decide the ownership. https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/api/openstack/compute/availability_zone.py#L111 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 We need to default the GET /os-availability-zone policy same as GET details /os-availability-zone which is admin. [1] - https://github.com/openstack/nova/blob/1fcd74730d343b7cee12a0a50ea537dc4ff87f65/nova/policies/availability_zone.py#L27 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1862484/+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 1861464] [NEW] os-attach-interfaces API policy is allowed for everyone even policy defaults is admin_or_owner
Public bug reported: os-attach-interfaces APi policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/705126/1 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/api/openstack/compute/attach_interfaces.py#L70 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policies/attach_interfaces.py#L28 ** 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/1861464 Title: os-attach-interfaces API policy is allowed for everyone even policy defaults is admin_or_owner Status in OpenStack Compute (nova): New Bug description: os-attach-interfaces APi policy is default to admin_or_owner[1] but API is allowed for everyone. We can see the test trying with other project context can access the API - https://review.opendev.org/#/c/705126/1 This is because API does not pass the server project_id in policy target - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/api/openstack/compute/attach_interfaces.py#L70 and if no target is passed then, policy.py add the default targets which is nothing but context.project_id (allow for everyone try to access) - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policy.py#L191 [1] - https://github.com/openstack/nova/blob/c16315165ce307c605cf4b608b2df3aa06f46982/nova/policies/attach_interfaces.py#L28 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1861464/+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 1859988] Re: neutron-tempest-plugin tests fail for stable/queens
** Changed in: devstack Status: Confirmed => Fix Released ** Changed in: tempest Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1859988 Title: neutron-tempest-plugin tests fail for stable/queens Status in devstack: Fix Released Status in neutron: Fix Released Status in tempest: Fix Released Bug description: Recent stable/queens backport fail on neutron-tempest-plugin scenario tests, sample here: https://c896d480cfbd9dee637c-6e2dfe610262db0cf157ed36bc183b08.ssl.cf2.rackcdn.com/688719/5/check/neutron-tempest-plugin-scenario-openvswitch-queens/f080f61/testr_results.html Traceback (most recent call last): File "tempest/common/utils/__init__.py", line 108, in wrapper return func(*func_args, **func_kwargs) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/scenario/test_internal_dns.py", line 72, in test_dns_domain_and_name timeout=CONF.validation.ping_timeout * 10) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/scenario/base.py", line 309, in check_remote_connectivity timeout=timeout)) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/scenario/base.py", line 299, in _check_remote_connectivity ping_remote, timeout or CONF.validation.ping_timeout, 1) File "tempest/lib/common/utils/test_utils.py", line 107, in call_until_true if func(*args, **kwargs): File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/scenario/base.py", line 283, in ping_remote fragmentation=fragmentation) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/scenario/base.py", line 278, in ping_host return source.exec_command(cmd) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/tenacity/__init__.py", line 311, in wrapped_f return self.call(f, *args, **kw) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/tenacity/__init__.py", line 391, in call do = self.iter(retry_state=retry_state) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/tenacity/__init__.py", line 338, in iter return fut.result() File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/concurrent/futures/_base.py", line 455, in result return self.__get_result() File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/tenacity/__init__.py", line 394, in call result = fn(*args, **kwargs) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/common/ssh.py", line 205, in exec_command return super(Client, self).exec_command(cmd=cmd, encoding=encoding) File "tempest/lib/common/ssh.py", line 153, in exec_command with transport.open_session() as channel: AttributeError: 'NoneType' object has no attribute 'open_session' Queens jobs were pinned to 0.7.0 version of the plugin in a4962ec62808fc469eaad73b1408447d8e3bc7ec it looks like we now need to also pin tempest itself to a "queens version" To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1859988/+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 1860033] Re: Tempest jobs broken on stable branches due to requirements neutron-lib upgrade (the EOLing python2 drama)
It is not required to backport on stable/queens as such. stable/queens has been pinned with compatible Tempest tag - https://review.opendev.org/#/c/703679/ ** Changed in: devstack Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1860033 Title: Tempest jobs broken on stable branches due to requirements neutron-lib upgrade (the EOLing python2 drama) Status in devstack: Fix Released Status in neutron: Confirmed Status in tempest: Fix Released Bug description: Updating neutron-lib to 2.0.0 (py3-only release) in upper constraints on master [1] killed neutron tempest rocky jobs with: 2020-01-16 19:07:29.088781 | controller | Processing /opt/stack/neutron-tempest-plugin 2020-01-16 19:07:29.825378 | controller | Requirement already satisfied: pbr===5.4.4 in ./.tox/tempest/lib/python2.7/site-packages (from -c u-c-m.txt (line 58)) (5.4.4) 2020-01-16 19:07:29.869691 | controller | Collecting neutron-lib===2.0.0 (from -c u-c-m.txt (line 79)) 2020-01-16 19:07:30.019373 | controller | Could not find a version that satisfies the requirement neutron-lib===2.0.0 (from -c u-c-m.txt (line 79)) (from versions: 0.0.1, 0.0.2, 0.0.3, 0.1.0, 0.2.0, 0.3.0, 0.4.0, 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.9.2, 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0, 1.15.0, 1.16.0, 1.17.0, 1.18.0, 1.19.0, 1.20.0, 1.21.0, 1.22.0, 1.23.0, 1.24.0, 1.25.0, 1.26.0, 1.27.0, 1.28.0, 1.29.0, 1.29.1, 1.30.0, 1.31.0) 2020-01-16 19:07:30.033128 | controller | No matching distribution found for neutron-lib===2.0.0 (from -c u-c-m.txt (line 79)) see [2] for an example log. These jobs run on Ubuntu 16.04 with Python 2. [1] https://review.opendev.org/702288 [2] https://f6bb8d2d9ae7bba883a1-1b1c7df97f8efc0930cf31e3404d1843.ssl.cf2.rackcdn.com/702946/1/check/neutron-tempest-plugin-api-rocky/9043fec/job-output.txt To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1860033/+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 1859988] Re: neutron-tempest-plugin tests fail for stable/queens
which change in queens s incompatible? that will help to understand the issue completely. Also queens is EM now and I am in progress to officially end the support of queens in Tempest[1]. After doing the release for Tempest, and based on change broke the Tempest queens we can pin the Tempest on devstack like we did for pike and ocata. There we can handle the upper-contraint things also as i mentioned in other bug (https://bugs.launchpad.net/neutron/+bug/1860033) otherwise pining alone would not solve the bug. [1] https://review.opendev.org/#/c/703255/ ** Also affects: tempest Importance: Undecided Status: New ** Also affects: devstack Importance: Undecided Status: New ** Changed in: tempest Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) ** Changed in: tempest Importance: Undecided => Critical -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1859988 Title: neutron-tempest-plugin tests fail for stable/queens Status in devstack: New Status in neutron: In Progress Status in tempest: New Bug description: Recent stable/queens backport fail on neutron-tempest-plugin scenario tests, sample here: https://c896d480cfbd9dee637c-6e2dfe610262db0cf157ed36bc183b08.ssl.cf2.rackcdn.com/688719/5/check/neutron-tempest-plugin-scenario-openvswitch-queens/f080f61/testr_results.html Traceback (most recent call last): File "tempest/common/utils/__init__.py", line 108, in wrapper return func(*func_args, **func_kwargs) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/scenario/test_internal_dns.py", line 72, in test_dns_domain_and_name timeout=CONF.validation.ping_timeout * 10) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/scenario/base.py", line 309, in check_remote_connectivity timeout=timeout)) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/scenario/base.py", line 299, in _check_remote_connectivity ping_remote, timeout or CONF.validation.ping_timeout, 1) File "tempest/lib/common/utils/test_utils.py", line 107, in call_until_true if func(*args, **kwargs): File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/scenario/base.py", line 283, in ping_remote fragmentation=fragmentation) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/scenario/base.py", line 278, in ping_host return source.exec_command(cmd) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/tenacity/__init__.py", line 311, in wrapped_f return self.call(f, *args, **kw) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/tenacity/__init__.py", line 391, in call do = self.iter(retry_state=retry_state) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/tenacity/__init__.py", line 338, in iter return fut.result() File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/concurrent/futures/_base.py", line 455, in result return self.__get_result() File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/tenacity/__init__.py", line 394, in call result = fn(*args, **kwargs) File "/opt/stack/tempest/.tox/tempest/local/lib/python2.7/site-packages/neutron_tempest_plugin/common/ssh.py", line 205, in exec_command return super(Client, self).exec_command(cmd=cmd, encoding=encoding) File "tempest/lib/common/ssh.py", line 153, in exec_command with transport.open_session() as channel: AttributeError: 'NoneType' object has no attribute 'open_session' Queens jobs were pinned to 0.7.0 version of the plugin in a4962ec62808fc469eaad73b1408447d8e3bc7ec it looks like we now need to also pin tempest itself to a "queens version" To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1859988/+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 1860033] Re: Tempest jobs broken on stable branches due to requirements neutron-lib upgrade (the EOLing python2 drama)
** 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 neutron. https://bugs.launchpad.net/bugs/1860033 Title: Tempest jobs broken on stable branches due to requirements neutron-lib upgrade (the EOLing python2 drama) Status in devstack: Confirmed Status in neutron: Confirmed Status in tempest: In Progress Bug description: Updating neutron-lib to 2.0.0 (py3-only release) in upper constraints on master [1] killed neutron tempest rocky jobs with: 2020-01-16 19:07:29.088781 | controller | Processing /opt/stack/neutron-tempest-plugin 2020-01-16 19:07:29.825378 | controller | Requirement already satisfied: pbr===5.4.4 in ./.tox/tempest/lib/python2.7/site-packages (from -c u-c-m.txt (line 58)) (5.4.4) 2020-01-16 19:07:29.869691 | controller | Collecting neutron-lib===2.0.0 (from -c u-c-m.txt (line 79)) 2020-01-16 19:07:30.019373 | controller | Could not find a version that satisfies the requirement neutron-lib===2.0.0 (from -c u-c-m.txt (line 79)) (from versions: 0.0.1, 0.0.2, 0.0.3, 0.1.0, 0.2.0, 0.3.0, 0.4.0, 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 1.7.0, 1.8.0, 1.9.0, 1.9.1, 1.9.2, 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0, 1.15.0, 1.16.0, 1.17.0, 1.18.0, 1.19.0, 1.20.0, 1.21.0, 1.22.0, 1.23.0, 1.24.0, 1.25.0, 1.26.0, 1.27.0, 1.28.0, 1.29.0, 1.29.1, 1.30.0, 1.31.0) 2020-01-16 19:07:30.033128 | controller | No matching distribution found for neutron-lib===2.0.0 (from -c u-c-m.txt (line 79)) see [2] for an example log. These jobs run on Ubuntu 16.04 with Python 2. [1] https://review.opendev.org/702288 [2] https://f6bb8d2d9ae7bba883a1-1b1c7df97f8efc0930cf31e3404d1843.ssl.cf2.rackcdn.com/702946/1/check/neutron-tempest-plugin-api-rocky/9043fec/job-output.txt To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1860033/+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 1849164] [NEW] nova policy doc does not include the PUT and Rebuild servers APIs for 'show:host_status' and 'os-extended-server-attributes'
Public bug reported:
In microversion 2.75, host_status and extended-server-attributes were
added in PUT /servers/{server-id} and POST /servers/action {rebuild }
API response with respective policy enforcement[1].
But PUT and rebuild APIs were missed to mentioned in policy doc for
'os_compute_api:servers:show:host_status' 'os_compute_api:os-extended-
server-attributes'
- https://docs.openstack.org/nova/latest/configuration/policy.html
[1]
https://github.com/openstack/nova/blob/964d7dc87989b5765fcc60d34f734963ab8e03e7/nova/api/openstack/compute/servers.py#L854
https://github.com/openstack/nova/blob/964d7dc87989b5765fcc60d34f734963ab8e03e7/nova/api/openstack/compute/servers.py#L1161
** Affects: nova
Importance: Undecided
Assignee: Ghanshyam Mann (ghanshyammann)
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/1849164
Title:
nova policy doc does not include the PUT and Rebuild servers APIs for
'show:host_status' and 'os-extended-server-attributes'
Status in OpenStack Compute (nova):
In Progress
Bug description:
In microversion 2.75, host_status and extended-server-attributes were
added in PUT /servers/{server-id} and POST /servers/action {rebuild }
API response with respective policy enforcement[1].
But PUT and rebuild APIs were missed to mentioned in policy doc for
'os_compute_api:servers:show:host_status' 'os_compute_api:os-extended-
server-attributes'
- https://docs.openstack.org/nova/latest/configuration/policy.html
[1]
https://github.com/openstack/nova/blob/964d7dc87989b5765fcc60d34f734963ab8e03e7/nova/api/openstack/compute/servers.py#L854
https://github.com/openstack/nova/blob/964d7dc87989b5765fcc60d34f734963ab8e03e7/nova/api/openstack/compute/servers.py#L1161
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1849164/+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 1836618] Re: Due to case sensitivity of a user name compare in a keystone test, the test might fail
Thanks for adding the more info. That seems strange for me that username is not kept same as it was input. case sensitive in keystone is based on backend but it should be consistent. I am adding keystone as an affected project in this bug to get provide input on why returned user name is not consistent in term of case sensitive. ** 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/1836618 Title: Due to case sensitivity of a user name compare in a keystone test, the test might fail Status in OpenStack Identity (keystone): New Status in tempest: In Progress Bug description: Due to case sensitivity of a user name compare in a keystone test, the test might return an error similar to the one below: Captured Traceback: Traceback (most recent call last): File "tempest/api/identity/v3/test_tokens.py", line 113, in test_token_auth_creation_existence_deletion self.assertEqual(token_details['user']['name'], user.username) File "/home/manasareddybethi/aqua-venv/local/lib/python2.7/site-packages/testtools/testcase.py", line 411, in assertEqual self.assertThat(observed, matcher, message) File "/home/manasareddybethi/aqua-venv/local/lib/python2.7/site-packages/testtools/testcase.py", line 498, in assertThat raise mismatch_error testtools.matchers._impl.MismatchError: u'KellyTest' != u'kellytest' This is because it is comparing the name from keystone and the name from tempest.conf or accounts.yaml, when using preprovisioned creds. Here is he example that I have on our openstack instance. mismatch error from the stack trace, u'KellyTest' != u'kellytest' the username for the project and username on accounts.yaml or tempest.conf are not identical. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1836618/+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 1819944] [NEW] nova-grenade-live-migration job failing on ubuntu bionic due to missing ceph package
Public bug reported: ceph hammer are not present in bionic and so nova-grenade-live-migration fail to run on bionic - https://review.openstack.org/#/c/639017/8 http://logs.openstack.org/17/639017/8/check/nova-grenade-live- migration/735242b/ara-report/result/8816413c-7053-418f-886b- e238fdea1ec5/ 10:59 AM E: Failed to fetch http://download.ceph.com/debian- hammer/dists/bionic/main/binary-amd64/Packages 404 Not Found [IP: 2607:5300:201:2000::3:58a1 80] ** Affects: nova Importance: Undecided Status: Confirmed ** Tags: ceph gate-failure grenade live-migration testing -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1819944 Title: nova-grenade-live-migration job failing on ubuntu bionic due to missing ceph package Status in OpenStack Compute (nova): Confirmed Bug description: ceph hammer are not present in bionic and so nova-grenade-live-migration fail to run on bionic - https://review.openstack.org/#/c/639017/8 http://logs.openstack.org/17/639017/8/check/nova-grenade-live- migration/735242b/ara-report/result/8816413c-7053-418f-886b- e238fdea1ec5/ 10:59 AM E: Failed to fetch http://download.ceph.com/debian- hammer/dists/bionic/main/binary-amd64/Packages 404 Not Found [IP: 2607:5300:201:2000::3:58a1 80] To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1819944/+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 1819794] [NEW] nova-next job fail on Ubuntu Bionic
Public bug reported: OpenStack CI is moving to Ubuntu Bionic. All zuulv3 native jobs based on devstack job are already running on bionic but legacy jobs are still running on xenial. While migrating the legacy jobs to Bionic, nova-next job start failing - https://review.openstack.org/#/c/639017 The problem seems to be on TLS console proxy side. This is the only legacy job which enables tls-proxy service. libvirt.libvirtError: internal error: process exited while connecting to monitor: 2019-03-08T02:23:53.402326Z qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] Mar 08 02:23:53.452557 ubuntu-bionic-rax-iad-0003574603 nova-compute[31993]: ERROR nova.virt.libvirt.driver [None req-a3dbdf7a-29cc-4e36-a760-2d92da2d13f0 tempest-DeleteServersAdminTestJSON-2130806780 tempest-DeleteServersAdminTestJSON-2130806780] [instance: 3b8927dd-fd26-4050-9428-d0db99856d60] Failed to start libvirt guest: libvirt.libvirtError: internal error: process exited while connecting to monitor: 2019-03-08T02:23:53.402326Z qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] Complete logs http://logs.openstack.org/17/639017/4/check/nova- next/566ea7a/logs/screen-n-cpu.txt.gz#_Mar_08_02_23_53_452557 http://logs.openstack.org/17/639017/4/check/nova- next/566ea7a/logs/screen-n-cond-cell1.txt.gz#_Mar_08_02_23_54_553579 ** 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/1819794 Title: nova-next job fail on Ubuntu Bionic Status in OpenStack Compute (nova): New Bug description: OpenStack CI is moving to Ubuntu Bionic. All zuulv3 native jobs based on devstack job are already running on bionic but legacy jobs are still running on xenial. While migrating the legacy jobs to Bionic, nova-next job start failing - https://review.openstack.org/#/c/639017 The problem seems to be on TLS console proxy side. This is the only legacy job which enables tls-proxy service. libvirt.libvirtError: internal error: process exited while connecting to monitor: 2019-03-08T02:23:53.402326Z qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] Mar 08 02:23:53.452557 ubuntu-bionic-rax-iad-0003574603 nova-compute[31993]: ERROR nova.virt.libvirt.driver [None req-a3dbdf7a-29cc-4e36-a760-2d92da2d13f0 tempest-DeleteServersAdminTestJSON-2130806780 tempest-DeleteServersAdminTestJSON-2130806780] [instance: 3b8927dd-fd26-4050-9428-d0db99856d60] Failed to start libvirt guest: libvirt.libvirtError: internal error: process exited while connecting to monitor: 2019-03-08T02:23:53.402326Z qemu-system-x86_64: warning: TCG doesn't support requested feature: CPUID.01H:ECX.vmx [bit 5] Complete logs http://logs.openstack.org/17/639017/4/check/nova- next/566ea7a/logs/screen-n-cpu.txt.gz#_Mar_08_02_23_53_452557 http://logs.openstack.org/17/639017/4/check/nova- next/566ea7a/logs/screen-n-cond-cell1.txt.gz#_Mar_08_02_23_54_553579 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1819794/+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 1641523] Re: Nova can't force-delete instance that is stuck in deleting process
*** This bug is a duplicate of bug 1741000 *** https://bugs.launchpad.net/bugs/1741000 This is duplicate of https://bugs.launchpad.net/nova/+bug/1741000 It is fixed by https://review.openstack.org/#/c/530879/ and fix is backported till stable/pike. Marking as duplicate of 1741000 ** This bug has been marked a duplicate of bug 1741000 Can't force-delete instance with task_state not 'None' -- 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/1641523 Title: Nova can't force-delete instance that is stuck in deleting process Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) newton series: In Progress Bug description: I tried to delete an instance that got into error state during creation. And it's stuck in deleting "Task State". I checked with virsh and instance is not present. And after I tried to force-delete it nova client crashed with a message that it should be reported as bug. Installation is Newton on Centos 7. Here is part of nova-api.log 2016-11-14 08:37:05.099 4189 INFO nova.osapi_compute.wsgi.server [req-37d453be-6f18-479d-bae8-6b24493a3366 24bef1856bf643c2bda92b710a7a6fcd 43dec04d0696450787fee3580b9780de - default default] 10.6.0.11 "GET /v2.1/ HTTP/1.1" status: 200 len: 714 time: 0.0065050 2016-11-14 08:37:05.569 4189 INFO nova.osapi_compute.wsgi.server [req-9a5d94a1-a2cf-45b8-bfac-5f231f3e07b7 24bef1856bf643c2bda92b710a7a6fcd 43dec04d0696450787fee3580b9780de - default default] 10.6.0.11 "GET /v2.1/43dec04d0696450787fee3580b9780de/servers/198b4ce6-84cc-4a45-8eda-d0b3262f3df4 HTTP/1.1" status: 200 len: 2243 time: 0.2764120 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions [req-fa12df45-bf9b-471b-8914-24a57427e358 24bef1856bf643c2bda92b710a7a6fcd 43dec04d0696450787fee3580b9780de - default default] Unexpected exception in API method 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 338, in wrapped 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/deferred_delete.py", line 64, in _force_delete 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions self.compute_api.force_delete(context, instance) 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 165, in inner 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions return function(self, context, instance, *args, **kwargs) 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 138, in inner 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions method=f.__name__) 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions InstanceInvalidState: Instance 198b4ce6-84cc-4a45-8eda-d0b3262f3df4 in task_state deleting. Cannot force_delete while the instance is in this state. 2016-11-14 08:37:05.651 4189 ERROR nova.api.openstack.extensions 2016-11-14 08:37:05.651 4189 INFO nova.api.openstack.wsgi [req-fa12df45-bf9b-471b-8914-24a57427e358 24bef1856bf643c2bda92b710a7a6fcd 43dec04d0696450787fee3580b9780de - default default] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1641523/+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 1704945] Re: nova force-delete can't delete instance in vm_state block_device_mapping
*** This bug is a duplicate of bug 1741000 ***
https://bugs.launchpad.net/bugs/1741000
This is duplicate of https://bugs.launchpad.net/nova/+bug/1741000
It is fixed by https://review.openstack.org/#/c/530879/ and fix is
backported till stable/pike.
Marking as duplicate of 1741000
** This bug has been marked a duplicate of bug 1741000
Can't force-delete instance with task_state not 'None'
--
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/1704945
Title:
nova force-delete can't delete instance in vm_state
block_device_mapping
Status in OpenStack Compute (nova):
In Progress
Bug description:
Description
===
when instance in block_device_mapping task state, can't force-delete it by
nova force-delete command.
Steps to reproduce
==
* Boot an instance, as soon as instance task state changed to
block_device_mapping, run nova force-delete INSTANCE_UUID command, get some
error:
# nova force-delete 08ed7e71-4470-4746-ae65-d17c659f29c9
/usr/lib/python2.7/site-packages/novaclient/client.py:278: UserWarning: The
'tenant_id' argument is deprecated in Ocata and its use may result in errors in
future releases. As 'project_id' is provided, the 'tenant_id' argument will be
ignored.
warnings.warn(msg)
ERROR (ClientException): Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
(HTTP 500) (Request-ID:
req-b185ecd7-5f0d-441e-8263-59af8b66aae7)
Expected result
===
force delete instance sucessfully
Actual result
=
get some error and force delete instance failed
Environment
===
# rpm -qa | grep nova
openstack-nova-api-15.0.0-1.el7.noarch
openstack-nova-console-15.0.0-1.el7.noarch
openstack-nova-common-15.0.0-1.el7.noarch
openstack-nova-conductor-15.0.0-1.el7.noarch
openstack-nova-novncproxy-15.0.0-1.el7.noarch
puppet-nova-10.3.0-1.el7.noarch
python-nova-15.0.0-1.el7.noarch
openstack-nova-cert-15.0.0-1.el7.noarch
openstack-nova-placement-api-15.0.0-1.el7.noarch
openstack-nova-compute-15.0.0-1.el7.noarch
openstack-nova-scheduler-15.0.0-1.el7.noarch
python2-novaclient-7.1.0-1.el7.noarch
Logs & Configs
==
2017-07-18 15:47:22.159 36543 DEBUG nova.api.openstack.wsgi
[req-b185ecd7-5f0d-441e-8263-59af8b66aae7 - - - - -] Action: 'action', calling
method: >, body: {"forceDelete": null} _process_stack
/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py:623
2017-07-18 15:47:22.159 36543 DEBUG nova.compute.api
[req-b185ecd7-5f0d-441e-8263-59af8b66aae7 - - - - -] [instance:
08ed7e71-4470-4746-ae65-d17c659f29c9] Fetching instance by UUID get
/usr/lib/python2.7/site-packages/nova/compute/api.py:2313
2017-07-18 15:47:22.172 36543 DEBUG oslo_db.sqlalchemy.engines
[req-b185ecd7-5f0d-441e-8263-59af8b66aae7 - - - - -] MySQL server mode set to
STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
_check_effective_sql_mode
/usr/lib/python2.7/site-packages/oslo_db/sqlalchemy/engines.py:261
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions
[req-b185ecd7-5f0d-441e-8263-59af8b66aae7 - - - - -] Unexpected exception in
API method
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions Traceback
(most recent call last):
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 338,
in wrapped
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions return
f(*args, **kwargs)
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/api/openstack/compute/deferred_delete.py",
line 64, in _force_delete
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions
self.compute_api.force_delete(context, instance)
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 170, in inner
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions return
function(self, context, instance, *args, **kwargs)
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions File
"/usr/lib/python2.7/site-packages/nova/compute/api.py", line 143, in inner
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions
method=f.__name__)
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions
InstanceInvalidState: Instance 08ed7e71-4470-4746-ae65-d17c659f29c9 in
task_state block_device_mapping. Cannot force_delete while the instance is in
this state.
2017-07-18 15:47:22.212 36543 ERROR nova.api.openstack.extensions
2017-07-18 15:47:22.219 36543 INFO nova.api.openstack.wsgi
[Yahoo-eng-team] [Bug 1791478] Re: nova-api get 504 when keepalived restart
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1791478
Title:
nova-api get 504 when keepalived restart
Status in OpenStack Compute (nova):
Invalid
Bug description:
With haproxy + keepalived in openstack controller service HA, it got
504 error:
first keystone:
DEBUG (base:176) Making authentication request to
http://192.168.21.1:35357/v3/auth/tokens
DEBUG (connectionpool:393) http://192.168.21.1:35357 "POST /v3/auth/tokens
HTTP/1.1" 504 None
DEBUG (session:868) Request returned failure status: 504
DEBUG (shell:791) Gateway Timeout (HTTP 504)
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 789, in
main
OpenStackComputeShell().main(argv)
File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 657, in
main
api_version = api_versions.discover_version(self.cs, api_version)
File "/usr/lib/python2.7/site-packages/novaclient/api_versions.py", line
261, in discover_version
client)
File "/usr/lib/python2.7/site-packages/novaclient/api_versions.py", line
242, in _get_server_version_range
version = client.versions.get_current()
File "/usr/lib/python2.7/site-packages/novaclient/v2/versions.py", line 70,
in get_current
return self._get_current()
File "/usr/lib/python2.7/site-packages/novaclient/v2/versions.py", line 52,
in _get_current
url = "%s" % self.api.client.get_endpoint()
File "/usr/lib/python2.7/site-packages/keystoneauth1/adapter.py", line 247,
in get_endpoint
return self.session.get_endpoint(auth or self.auth, **kwargs)
File "/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line
1113, in get_endpoint
return auth.get_endpoint(self, **kwargs)
File "/usr/lib/python2.7/site-packages/keystoneauth1/identity/base.py",
line 380, in get_endpoint
allow_version_hack=allow_version_hack, **kwargs)
File "/usr/lib/python2.7/site-packages/keystoneauth1/identity/base.py",
line 271, in get_endpoint_data
service_catalog = self.get_access(session).service_catalog
File "/usr/lib/python2.7/site-packages/keystoneauth1/identity/base.py",
line 134, in get_access
self.auth_ref = self.get_auth_ref(session)
File
"/usr/lib/python2.7/site-packages/keystoneauth1/identity/generic/base.py", line
208, in get_auth_ref
return self._plugin.get_auth_ref(session, **kwargs)
File "/usr/lib/python2.7/site-packages/keystoneauth1/identity/v3/base.py",
line 178, in get_auth_ref
authenticated=False, log=False, **rkwargs)
File "/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line
1019, in post
return self.request(url, 'POST', **kwargs)
File "/usr/lib/python2.7/site-packages/keystoneauth1/session.py", line 869,
in request
raise exceptions.from_response(resp, method, url)
GatewayTimeout: Gateway Timeout (HTTP 504)
ERROR (GatewayTimeout): Gateway Timeout (HTTP 504)
then after about 1 min, keystone has worked but nova-api:
DEBUG (connectionpool:205) Starting new HTTP connection (1): 10.22.21.1:8774
DEBUG (connectionpool:393) http://10.22.21.1:8774 "GET
/v2.1/75bd7e950f4b4792a486b6bf240c7a3d HTTP/1.1" 404 112
RESP: [404] Content-Length: 112 Content-Type: application/json; charset=UTF-8
Date: Sun, 09 Sep 2018 00:56:18 GMT X-Compute-Request-Id:
req-9e16a30b-3407-4f4f-89d7-1b64f4637b25
DEBUG (session:479) RESP: [404] Content-Length: 112 Content-Type:
application/json; charset=UTF-8 Date: Sun, 09 Sep 2018 00:56:18 GMT
X-Compute-Request-Id: req-9e16a30b-3407-4f4f-89d7-1b64f4637b25
RESP BODY: {"message": "The resource could not be found.\n\n\n",
"code": "404 Not Found", "title": "Not Found"}
DEBUG (session:511) RESP BODY: {"message": "The resource could not be
found.\n\n\n", "code": "404 Not Found", "title": "Not Found"}
It reported service not found, and then got the 504:
DEBUG (session:448) REQ: curl -g -i -X GET
http://192.168.21.1:8774/v2.1/75bd7e950f4b4792a486b6bf240c7a3d/servers/detail
-H "Accept: application/json" -H "OpenStack-API-Version: compute 2.42" -H
"User-Agent: python-novaclient" -H "X-Auth-Token:
{SHA1}d0dd50b3f49d2ab39fae428e4eff0050bb2088ab" -H
"X-OpenStack-Nova-API-Version: 2.42"
DEBUG (connectionpool:393) http://192.168.21.1:8774 "GET
/v2.1/75bd7e950f4b4792a486b6bf240c7a3d/servers/detail HTTP/1.1" 504 None
DEBUG (session:479) RESP: [504] Cache-Control: no-cache Connection: close
Content-Type: text/html
DEBUG (session:511) RESP BODY: Omitted, Content-Type is set to text/html.
Only application/json responses have their bodies logged.
DEBUG (shell:791) Unknown Error (HTTP 504)
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/novaclient/shell.py", line 789, in
main
OpenStackComputeShell().main(argv)
File
[Yahoo-eng-team] [Bug 1803861] Re: Unexpected API Error.
And releasenotes and doc has been fixed for nova-consoleauth
requirement-
https://review.openstack.org/#/q/4f01f4ff88de571218a36ba7c4e998296a7b52a4
** Changed in: nova
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1803861
Title:
Unexpected API Error.
Status in OpenStack Compute (nova):
Invalid
Bug description:
Description
===
ClientException: Unexpected API Error has returned when I perform below
command:
$ openstack console url show provider-instance
Steps to reproduce
==
* I following Rocky install-guide for Ubuntu. then I did perform above
command after the instance launched for access virtual console.
(https://docs.openstack.org/install-guide/launch-instance-provider.html)
For further investigating, openstack client command with debug option
like below.
---
REQ: curl -g -i -X POST
http://CONTROLLER:8774/v2.1/servers/0892b6b0-15b9-4ee9-bd72-6ea124e36721/action
-H "Accept: application/json" -H "Content-Type: application/json" -H
"User-Agent: python-novaclient" -H "X-Auth-Token:
{SHA1}ce0fa2f294403fb0799374c146609be3328d2006" -d '{"os-getVNCConsole":
{"type": "novnc"}}'
http://CONTROLLER:8774 "POST
/v2.1/servers/0892b6b0-15b9-4ee9-bd72-6ea124e36721/action HTTP/1.1" 500 216
RESP: [500] Connection: keep-alive Content-Length: 216 Content-Type:
application/json; charset=UTF-8 Date: Sun, 18 Nov 2018 10:56:58 GMT
Openstack-Api-Version: compute 2.1 Vary: OpenStack-API-Version,
X-OpenStack-Nova-API-Version X-Compute-Request-Id:
req-0485f3c1-155b-4000-9474-6197a7039577 X-Openstack-Nova-Api-Version: 2.1
X-Openstack-Request-Id: req-0485f3c1-155b-4000-9474-6197a7039577
RESP BODY: {"computeFault": {"message": "Unexpected API Error. Please report
this at http://bugs.launchpad.net/nova/ and attach the Nova API log if
possible.\n", "code": 500}}
POST call to compute for
http://CONTROLLER:8774/v2.1/servers/0892b6b0-15b9-4ee9-bd72-6ea124e36721/action
used request id req-0485f3c1-155b-4000-9474-6197a7039577
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/
and attach the Nova API log if possible.
(HTTP 500) (Request-ID:
req-0485f3c1-155b-4000-9474-6197a7039577)
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/cliff/app.py", line 400, in
run_subcommand
result = cmd.run(parsed_args)
File "/usr/lib/python2.7/dist-packages/osc_lib/command/command.py", line
41, in run
return super(Command, self).run(parsed_args)
File "/usr/lib/python2.7/dist-packages/cliff/display.py", line 116, in run
column_names, data = self.take_action(parsed_args)
File
"/usr/lib/python2.7/dist-packages/openstackclient/compute/v2/console.py", line
130, in take_action
data = server.get_console_url(parsed_args.url_type)
File "/usr/lib/python2.7/dist-packages/novaclient/v2/servers.py", line 147,
in get_console_url
return self.manager.get_console_url(self, console_type)
File "/usr/lib/python2.7/dist-packages/novaclient/api_versions.py", line
393, in substitution
return methods[-1].func(obj, *args, **kwargs)
File "/usr/lib/python2.7/dist-packages/novaclient/v2/servers.py", line 931,
in get_console_url
return self._action(action, server, {'type': console_type})
File "/usr/lib/python2.7/dist-packages/novaclient/v2/servers.py", line
1918, in _action
info=info, **kwargs)
File "/usr/lib/python2.7/dist-packages/novaclient/v2/servers.py", line
1929, in _action_return_resp_and_body
return self.api.client.post(url, body=body)
File "/usr/lib/python2.7/dist-packages/keystoneauth1/adapter.py", line 334,
in post
return self.request(url, 'POST', **kwargs)
File "/usr/lib/python2.7/dist-packages/novaclient/client.py", line 83, in
request
raise exceptions.from_response(resp, body, url, method)
ClientException: Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
(HTTP 500) (Request-ID:
req-0485f3c1-155b-4000-9474-6197a7039577)
clean_up ShowConsoleURL: Unexpected API Error. Please report this at
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
(HTTP 500) (Request-ID:
req-0485f3c1-155b-4000-9474-6197a7039577)
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/osc_lib/shell.py", line 135, in run
ret_val = super(OpenStackShell, self).run(argv)
File "/usr/lib/python2.7/dist-packages/cliff/app.py", line 279, in run
result = self.run_subcommand(remainder)
File "/usr/lib/python2.7/dist-packages/osc_lib/shell.py", line 175, in
run_subcommand
ret_value = super(OpenStackShell, self).run_subcommand(argv)
File "/usr/lib/python2.7/dist-packages/cliff/app.py", line 400, in
run_subcommand
result =
[Yahoo-eng-team] [Bug 1737338] Re: Normal response code of addSecurityGroup is wrong
Yea, there are lot of other place where API status code are not consistent and as per guidelines. As jichenjc mentioned this will be API change and need microversion bump to maintain the backward compatibility. And as per Nova process, every API change needs spec, so please write spec for this for further discussion. ** Changed in: nova Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1737338 Title: Normal response code of addSecurityGroup is wrong Status in OpenStack Compute (nova): Invalid Bug description: Description === According to nova's api-ref [1], the normal response code of addSecurityGroup is 202. However, according to OpenStack API guideline [2] , 202 is for "Asynchronous resource creation" but the addSecurityGroup action doesn't seem to be async. I think 200 is more appropriate in this case. [1] https://developer.openstack.org/api-ref/compute/#add-security-group-to-a-server-addsecuritygroup-action [2] http://specs.openstack.org/openstack/api-wg/guidelines/http.html#xx-success-codes To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1737338/+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 1468992] Re: nova list's --tenant filter does not return expected servers
Just updating the latest comments. This is API change and we need spec for any API change. This is not priority for Rocky and i will check and discuss in API meeting if we can do and it is worth to do in stein. Or it is ok to just fix the python client. Marking invalid for tempest as tempest is testing the right behavior of API. ** Changed in: tempest Status: Triaged => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1468992 Title: nova list's --tenant filter does not return expected servers Status in OpenStack Compute (nova): Triaged Status in tempest: Invalid Bug description: This bug is opened as fix released for https://bugs.launchpad.net/nova/+bug/1185290 is reverted back in v2.1. Fix proposed in v3 was reverted/commented out in v2.1 to make v2.1 fully compatible and identical with v2. - https://review.openstack.org/#/c/145687/ We need to fix this for both v2 and v2.1 APIs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1468992/+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 1734427] [NEW] 'all_tenants' 'all_projects' query param is not only integer as mentioned in api-ref
Public bug reported: 'all_tenants' and 'all_projects' are query param to list the resources for all tenants/projects. Checking of this query param in code is different in different APIs. - GET /servers API checks the value of 'all_tenants' as bool[1]. - other APIs just checks the present of it in req, like GET /os-server-groups, /os-fping api-ref mentioned this param types as integer, boolean or string. It is good to mention this query param type consistently to avoid confusion for users. ..1 https://github.com/openstack/nova/blob/e9104dbaef9bbccc6b19811125d439fdf9558428/nova/api/openstack/compute/servers.py#L265 ..2 https://github.com/openstack/nova/blob/e9104dbaef9bbccc6b19811125d439fdf9558428/nova/api/openstack/compute/server_groups.py#L138 https://github.com/openstack/nova/blob/e9104dbaef9bbccc6b19811125d439fdf9558428/nova/api/openstack/compute/fping.py#L75 ** Affects: nova Importance: Undecided Assignee: Ghanshyam Mann (ghanshyammann) Status: In Progress ** Changed in: nova Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) -- 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/1734427 Title: 'all_tenants' 'all_projects' query param is not only integer as mentioned in api-ref Status in OpenStack Compute (nova): In Progress Bug description: 'all_tenants' and 'all_projects' are query param to list the resources for all tenants/projects. Checking of this query param in code is different in different APIs. - GET /servers API checks the value of 'all_tenants' as bool[1]. - other APIs just checks the present of it in req, like GET /os-server-groups, /os-fping api-ref mentioned this param types as integer, boolean or string. It is good to mention this query param type consistently to avoid confusion for users. ..1 https://github.com/openstack/nova/blob/e9104dbaef9bbccc6b19811125d439fdf9558428/nova/api/openstack/compute/servers.py#L265 ..2 https://github.com/openstack/nova/blob/e9104dbaef9bbccc6b19811125d439fdf9558428/nova/api/openstack/compute/server_groups.py#L138 https://github.com/openstack/nova/blob/e9104dbaef9bbccc6b19811125d439fdf9558428/nova/api/openstack/compute/fping.py#L75 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1734427/+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 1734406] [NEW] 'all_tenants' query param is missing in GET sec group api-ref
Public bug reported: GET Security group API accept 'all_tenants' [1] as one of the query param to list all tenants sec group. But that is missing in api-ref [2] ..1 https://github.com/openstack/nova/blob/e9104dbaef9bbccc6b19811125d439fdf9558428/nova/network/security_group/neutron_driver.py#L178 https://github.com/openstack/nova/blob/e9104dbaef9bbccc6b19811125d439fdf9558428/nova/compute/api.py#L5096 ..2 https://developer.openstack.org/api-ref/compute/#list-security- groups ** Affects: nova Importance: Undecided Assignee: Ghanshyam Mann (ghanshyammann) Status: New ** Changed in: nova Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) -- 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/1734406 Title: 'all_tenants' query param is missing in GET sec group api-ref Status in OpenStack Compute (nova): New Bug description: GET Security group API accept 'all_tenants' [1] as one of the query param to list all tenants sec group. But that is missing in api-ref [2] ..1 https://github.com/openstack/nova/blob/e9104dbaef9bbccc6b19811125d439fdf9558428/nova/network/security_group/neutron_driver.py#L178 https://github.com/openstack/nova/blob/e9104dbaef9bbccc6b19811125d439fdf9558428/nova/compute/api.py#L5096 ..2 https://developer.openstack.org/api-ref/compute/#list-security- groups To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1734406/+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 1703844] Re: api-ref for GET os-instance-actions does not list event's key(start_time etc) as optional
after discussion on patch and IRC, i agree that from api-ref perspective
this might be more confusing to mention as optional. It can be read as
start_time can be present or not as alone which is not true all other
events attributes are all together either present or not.
** Changed in: nova
Status: In Progress => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1703844
Title:
api-ref for GET os-instance-actions does not list event's
key(start_time etc) as optional
Status in OpenStack Compute (nova):
Invalid
Bug description:
GET os-instance-actions can return 'events' key in response if it
corresponding policy permit it.
'events' in response is list of following elements:
{'event', 'start_time', 'finish_time', 'result', 'traceback'}
API ref mentioned those elements in 'events' response key as mandatory
which is not the case.
https://developer.openstack.org/api-ref/compute/?expanded=show-server-
action-details-detail#show-server-action-details
'events' response key can be empty list.
Events in DB are being created when event_start() is called from
decorator wrap_instance_event()
https://github.com/openstack/nova/blob/0ffe7b27892fde243fc1006f800f309c10d66028/nova/objects/instance_action.py#L169
https://github.com/openstack/nova/blob/0ffe7b27892fde243fc1006f800f309c10d66028/nova/db/sqlalchemy/api.py#L6159
and if no events in DB then API controller going to return 'events' as
empty list.
https://github.com/openstack/nova/blob/0ffe7b27892fde243fc1006f800f309c10d66028/nova/api/openstack/compute/instance_actions.py#L86
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1703844/+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 1703844] [NEW] api-ref for GET os-instance-actions does not list event's key(start_time etc) as optional
Public bug reported:
GET os-instance-actions can return 'events' key in response if it corresponding
policy permit it.
'events' in response is list of following elements:
{'event', 'start_time', 'finish_time', 'result', 'traceback'}
API ref mentioned those elements in 'events' response key as mandatory
which is not the case.
https://developer.openstack.org/api-ref/compute/?expanded=show-server-
action-details-detail#show-server-action-details
'events' response key can be empty list.
Events in DB are being created when event_start() is called from
decorator wrap_instance_event()
https://github.com/openstack/nova/blob/0ffe7b27892fde243fc1006f800f309c10d66028/nova/objects/instance_action.py#L169
https://github.com/openstack/nova/blob/0ffe7b27892fde243fc1006f800f309c10d66028/nova/db/sqlalchemy/api.py#L6159
and if no events in DB then API controller going to return 'events' as
empty list.
https://github.com/openstack/nova/blob/0ffe7b27892fde243fc1006f800f309c10d66028/nova/api/openstack/compute/instance_actions.py#L86
** Affects: nova
Importance: Undecided
Assignee: Ghanshyam Mann (ghanshyammann)
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/1703844
Title:
api-ref for GET os-instance-actions does not list event's
key(start_time etc) as optional
Status in OpenStack Compute (nova):
New
Bug description:
GET os-instance-actions can return 'events' key in response if it
corresponding policy permit it.
'events' in response is list of following elements:
{'event', 'start_time', 'finish_time', 'result', 'traceback'}
API ref mentioned those elements in 'events' response key as mandatory
which is not the case.
https://developer.openstack.org/api-ref/compute/?expanded=show-server-
action-details-detail#show-server-action-details
'events' response key can be empty list.
Events in DB are being created when event_start() is called from
decorator wrap_instance_event()
https://github.com/openstack/nova/blob/0ffe7b27892fde243fc1006f800f309c10d66028/nova/objects/instance_action.py#L169
https://github.com/openstack/nova/blob/0ffe7b27892fde243fc1006f800f309c10d66028/nova/db/sqlalchemy/api.py#L6159
and if no events in DB then API controller going to return 'events' as
empty list.
https://github.com/openstack/nova/blob/0ffe7b27892fde243fc1006f800f309c10d66028/nova/api/openstack/compute/instance_actions.py#L86
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1703844/+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 1702310] [NEW] Unclear description of 'disable-log-reason' api-ref
Public bug reported: 'disable-log-reason' API action disable the compute service and log the disabled reason. But api-ref statement sounds like this API only log the disable reason. - https://developer.openstack.org/api-ref/compute/#log-disabled-compute- service-information ** Affects: nova Importance: Undecided Assignee: Ghanshyam Mann (ghanshyammann) 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/1702310 Title: Unclear description of 'disable-log-reason' api-ref Status in OpenStack Compute (nova): In Progress Bug description: 'disable-log-reason' API action disable the compute service and log the disabled reason. But api-ref statement sounds like this API only log the disable reason. - https://developer.openstack.org/api-ref/compute/#log-disabled- compute-service-information To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1702310/+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 1702238] [NEW] 'project_id' & 'user_id' are required keys in server group APIs
Public bug reported: 'project_id' and 'user_id' are introduced as mandatory param in microversion 2.13 but api-ref shows them as optional - https://developer.openstack.org/api-ref/compute/?expanded=show-server- group-details-detail#show-server-group-details api-ref should be fixed to reflect the actual behavior. ** Affects: nova Importance: Undecided Assignee: Ghanshyam Mann (ghanshyammann) Status: New ** Changed in: nova Assignee: (unassigned) => Ghanshyam Mann (ghanshyammann) -- 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/1702238 Title: 'project_id' & 'user_id' are required keys in server group APIs Status in OpenStack Compute (nova): New Bug description: 'project_id' and 'user_id' are introduced as mandatory param in microversion 2.13 but api-ref shows them as optional - https://developer.openstack.org/api-ref/compute/?expanded=show-server- group-details-detail#show-server-group-details api-ref should be fixed to reflect the actual behavior. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1702238/+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 1702201] [NEW] 'networks' quota info missing in quota api-ref
Public bug reported: 'networks' quota can be available based on config value. api-ref should show that for quota-set and quota-class APIs and also sample files so that it can be tested somewhere. As those are deprecated with 2.35 in quota-set APIs (not in quota class), its good to have such info in api doc. ** Affects: nova Importance: Undecided Assignee: Ghanshyam Mann (ghanshyammann) 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/1702201 Title: 'networks' quota info missing in quota api-ref Status in OpenStack Compute (nova): In Progress Bug description: 'networks' quota can be available based on config value. api-ref should show that for quota-set and quota-class APIs and also sample files so that it can be tested somewhere. As those are deprecated with 2.35 in quota-set APIs (not in quota class), its good to have such info in api doc. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1702201/+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 1693168] [NEW] Different APIs 'os-quota-class-sets' Response between v2 and v2.1
Public bug reported: 'os-quota-class-sets' GET and PUT APIs response is different between v2(all extensions) and v2.1 There is no 'server_groups' and 'server_group_members' in quota class set APIs response where these were present in v2 (with all extension). 'os-server-group-quotas' extension was introduced in this - I78974602d4be04deaf173b3e43f2dab92e8f4171 in v2 API. and if extension 'os-server-group-quotas' was enabled in v2, then 'server_groups' and 'server_group_members' were present in APIs response. This behavior was till we had the legacy_v2 code where this extensions class and way to enable/disable extensions was available. In v2.1 API, there was never such extensions. v2.1 should behave same as v2 with all extensions. But we forgot to merge the if/else extension code[1] which caused 'server_groups' and 'server_group_members' never showed up in quota class set APIs (GET and PUT) response. .. 1 http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/quota_classes.py#n47 This issue did not get caught on tests as legacy_v2 code got removed before functional tests with all extensions were enabled. And somehow sample file with 'server_groups' and 'server_group_members' attributes in response got disappeared while changing the directory structure v3->v2.1>/compute etc. ** 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/1693168 Title: Different APIs 'os-quota-class-sets' Response between v2 and v2.1 Status in OpenStack Compute (nova): New Bug description: 'os-quota-class-sets' GET and PUT APIs response is different between v2(all extensions) and v2.1 There is no 'server_groups' and 'server_group_members' in quota class set APIs response where these were present in v2 (with all extension). 'os-server-group-quotas' extension was introduced in this - I78974602d4be04deaf173b3e43f2dab92e8f4171 in v2 API. and if extension 'os-server-group-quotas' was enabled in v2, then 'server_groups' and 'server_group_members' were present in APIs response. This behavior was till we had the legacy_v2 code where this extensions class and way to enable/disable extensions was available. In v2.1 API, there was never such extensions. v2.1 should behave same as v2 with all extensions. But we forgot to merge the if/else extension code[1] which caused 'server_groups' and 'server_group_members' never showed up in quota class set APIs (GET and PUT) response. .. 1 http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/quota_classes.py#n47 This issue did not get caught on tests as legacy_v2 code got removed before functional tests with all extensions were enabled. And somehow sample file with 'server_groups' and 'server_group_members' attributes in response got disappeared while changing the directory structure v3->v2.1>/compute etc. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1693168/+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 1504641] Re: Listing volumes respects osapi_max_limit but does not provide a link to the next element
** Changed in: nova
Status: New => Won't Fix
--
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/1504641
Title:
Listing volumes respects osapi_max_limit but does not provide a link
to the next element
Status in OpenStack Compute (nova):
Won't Fix
Status in tempest:
Won't Fix
Bug description:
When GETting os-volumes, the returned list of volumes respects the
osapi_max_limit configuration parameter but does not provide a link to
the next element in the list. For example, with two volumes configured
and osapi_max_limit set to 1, GETting volumes results in the
following:
{
"volumes": [
{
"attachments": [
{}
],
"availabilityZone": "nova",
"createdAt": "2015-10-09T18:12:04.00",
"displayDescription": null,
"displayName": null,
"id": "08792e26-204b-4bb9-8e9b-0e37331de51c",
"metadata": {},
"size": 1,
"snapshotId": null,
"status": "error",
"volumeType": "lvmdriver-1"
}
]
}
Unsetting osapi_max_limit results in both volumes being listed:
{
"volumes": [
{
"attachments": [
{}
],
"availabilityZone": "nova",
"createdAt": "2015-10-09T18:12:04.00",
"displayDescription": null,
"displayName": null,
"id": "08792e26-204b-4bb9-8e9b-0e37331de51c",
"metadata": {},
"size": 1,
"snapshotId": null,
"status": "error",
"volumeType": "lvmdriver-1"
},
{
"attachments": [
{}
],
"availabilityZone": "nova",
"createdAt": "2015-10-09T18:12:00.00",
"displayDescription": null,
"displayName": null,
"id": "5cf46cd2-8914-4ffd-9037-abd53c55ca76",
"metadata": {},
"size": 1,
"snapshotId": null,
"status": "error",
"volumeType": "lvmdriver-1"
}
]
}
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1504641/+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
