[Yahoo-eng-team] [Bug 1947146] [NEW] 'qemu-img: command not found' when testing on Centos
Public bug reported:
While running the tests for Glance on Centos, the 'qemu-img' is failing due to
missing qemu-img command[1]:
~~~
/bin/sh: qemu-img: command not found
{4}
glance.tests.functional.test_healthcheck_middleware.HealthcheckMiddlewareTest.test_healthcheck_enabled
[6.082316s] ... ok
{2}
glance.tests.functional.v2.test_images.TestImages.test_owning_tenant_can_communitize_image
[5.017702s] ... ok
{7}
glance.tests.functional.test_cache_middleware.TestImageCacheSqlite.test_partial_download_of_cached_images_v2_api
[6.331016s] ... ok
{7}
glance.tests.functional.test_client_redirects.TestClientRedirects.test_redirect_to_new_host
[0.033611s] ... ok
{6} glance.tests.functional.test_logging.TestLogging.test_no_debug [6.030891s]
... ok
{6} glance.tests.functional.test_sqlite.TestSqlite.test_big_int_mapping ...
SKIPPED: test requires exe: sqlite3
{5}
glance.tests.functional.v2.test_images.TestImageDirectURLVisibility.test_image_direct_url_visible
[3.947811s] ... ok
{3}
glance.tests.functional.v2.test_images.TestImages.test_image_import_qcow_virtual_size_calculation
[5.023139s] ... FAILED
Captured traceback:
~~~
Traceback (most recent call last):
File
"/home/zuul/src/opendev.org/openstack/glance/glance/tests/functional/v2/test_images.py",
line 959, in test_image_import_qcow_virtual_size_calculation
fn = self._create_qcow(128 * units.Mi)
File
"/home/zuul/src/opendev.org/openstack/glance/glance/tests/functional/v2/test_images.py",
line 911, in _create_qcow
shell=True)
File "/usr/lib64/python3.6/subprocess.py", line 356, in check_output
**kwargs).stdout
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command 'qemu-img create -f qcow2
/tmp/glance-unittest-images-05gx9_p1.qcow2 134217728' returned non-zero exit
status 127.
~~~
We need to add qemu-img on the bindep.txt to have it working on Centos.
[1]
https://zuul.opendev.org/t/openstack/build/b1e5959024d34af795912478ac9809ff/console
** Affects: glance
Importance: Undecided
Status: In Progress
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1947146
Title:
'qemu-img: command not found' when testing on Centos
Status in Glance:
In Progress
Bug description:
While running the tests for Glance on Centos, the 'qemu-img' is failing due
to missing qemu-img command[1]:
~~~
/bin/sh: qemu-img: command not found
{4}
glance.tests.functional.test_healthcheck_middleware.HealthcheckMiddlewareTest.test_healthcheck_enabled
[6.082316s] ... ok
{2}
glance.tests.functional.v2.test_images.TestImages.test_owning_tenant_can_communitize_image
[5.017702s] ... ok
{7}
glance.tests.functional.test_cache_middleware.TestImageCacheSqlite.test_partial_download_of_cached_images_v2_api
[6.331016s] ... ok
{7}
glance.tests.functional.test_client_redirects.TestClientRedirects.test_redirect_to_new_host
[0.033611s] ... ok
{6} glance.tests.functional.test_logging.TestLogging.test_no_debug
[6.030891s] ... ok
{6} glance.tests.functional.test_sqlite.TestSqlite.test_big_int_mapping ...
SKIPPED: test requires exe: sqlite3
{5}
glance.tests.functional.v2.test_images.TestImageDirectURLVisibility.test_image_direct_url_visible
[3.947811s] ... ok
{3}
glance.tests.functional.v2.test_images.TestImages.test_image_import_qcow_virtual_size_calculation
[5.023139s] ... FAILED
Captured traceback:
~~~
Traceback (most recent call last):
File
"/home/zuul/src/opendev.org/openstack/glance/glance/tests/functional/v2/test_images.py",
line 959, in test_image_import_qcow_virtual_size_calculation
fn = self._create_qcow(128 * units.Mi)
File
"/home/zuul/src/opendev.org/openstack/glance/glance/tests/functional/v2/test_images.py",
line 911, in _create_qcow
shell=True)
File "/usr/lib64/python3.6/subprocess.py", line 356, in check_output
**kwargs).stdout
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command 'qemu-img create -f qcow2
/tmp/glance-unittest-images-05gx9_p1.qcow2 134217728' returned non-zero exit
status 127.
~~~
We need to add qemu-img on the bindep.txt to have it working on
Centos.
[1]
https://zuul.opendev.org/t/openstack/build/b1e5959024d34af795912478ac9809ff/console
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1947146/+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 1946457] [NEW] Functional test fails with a: "Unknown file format 'qcow'" error on Centos8
Public bug reported:
This issue was discovered on tests with FIPS enabled[1], but without FIPS the
same issue happens.
When running glance functional tests on a Centos8 server, the following issue
happens:
{1}
glance.tests.functional.v2.test_images.TestImages.test_image_upload_qcow_virtual_size_calculation
[5.522514s] ... FAILED
Captured traceback:
~~~
Traceback (most recent call last):
File
"/home/zuul/src/opendev.org/openstack/glance/glance/tests/functional/v2/test_images.py",
line 931, in test_image_upload_qcow_virtual_size_calculation
fn = self._create_qcow(128 * units.Mi)
File
"/home/zuul/src/opendev.org/openstack/glance/glance/tests/functional/v2/test_images.py",
line 914, in _create_qcow
shell=True)
File "/usr/lib64/python3.6/subprocess.py", line 356, in check_output
**kwargs).stdout
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command 'qemu-img create -f qcow
/tmp/glance-unittest-images-5flalm7e.qcow 134217728' returned non-zero exit
status 127.
~~~
Trying to run this command manually on a Centos8 server with qemu-img installed
(qemu-img-15:4.2.0-48): qemu-img create -f qcow
/tmp/glance-unittest-images-5flalm7e.qcow 134217728
Initially it fails due to a gcrypt issue:
~~~
$ qemu-img create -f qcow /tmp/glance-unittest-images-5flalm7e.qcow 134217728
qemu-img: Unable to initialize gcrypt
~~~
There is a bug for this that[2] and the solution is to update the libgcrypt
package. Previously I had 'libgcrypt-1.8.3-4' and updated to:
'libgcrypt-1.8.5-4'.
After this, I got the "Unknown file format 'qcow'" error:
~~~
$ qemu-img create -f qcow /tmp/glance-unittest-images-5flalm7e.qcow 134217728
qemu-img: /tmp/glance-unittest-images-5flalm7e.qcow: Unknown file format 'qcow'
$ qemu-img create -f qcow2 /tmp/glance-unittest-images-5flalm7e.qcow 134217728
Formatting '/tmp/glance-unittest-images-5flalm7e.qcow', fmt=qcow2
size=134217728 cluster_size=65536 lazy_refcounts=off refcount_bits=16
~~~
Looking at our documentation I believe we don't support qcow format anymore[3],
so should we still keep this test? Or maybe, change it to use qcow2 instead of
qcow?
I believe that the reason we didn't see this issue on the CI's, is because they
are testing on a Ubuntu server (At least for the patch I analysed).
[1]
https://zuul.opendev.org/t/openstack/build/4f3a50281bc44ada9fb68ac24236cf1c/console
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1828681
[3] https://docs.openstack.org/glance/train/user/formats.html#disk-
format
** Affects: glance
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1946457
Title:
Functional test fails with a: "Unknown file format 'qcow'" error on
Centos8
Status in Glance:
New
Bug description:
This issue was discovered on tests with FIPS enabled[1], but without FIPS the
same issue happens.
When running glance functional tests on a Centos8 server, the following issue
happens:
{1}
glance.tests.functional.v2.test_images.TestImages.test_image_upload_qcow_virtual_size_calculation
[5.522514s] ... FAILED
Captured traceback:
~~~
Traceback (most recent call last):
File
"/home/zuul/src/opendev.org/openstack/glance/glance/tests/functional/v2/test_images.py",
line 931, in test_image_upload_qcow_virtual_size_calculation
fn = self._create_qcow(128 * units.Mi)
File
"/home/zuul/src/opendev.org/openstack/glance/glance/tests/functional/v2/test_images.py",
line 914, in _create_qcow
shell=True)
File "/usr/lib64/python3.6/subprocess.py", line 356, in check_output
**kwargs).stdout
File "/usr/lib64/python3.6/subprocess.py", line 438, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command 'qemu-img create -f qcow
/tmp/glance-unittest-images-5flalm7e.qcow 134217728' returned non-zero exit
status 127.
~~~
Trying to run this command manually on a Centos8 server with qemu-img
installed (qemu-img-15:4.2.0-48): qemu-img create -f qcow
/tmp/glance-unittest-images-5flalm7e.qcow 134217728
Initially it fails due to a gcrypt issue:
~~~
$ qemu-img create -f qcow /tmp/glance-unittest-images-5flalm7e.qcow 134217728
qemu-img: Unable to initialize gcrypt
~~~
There is a bug for this that[2] and the solution is to update the libgcrypt
package. Previously I had 'libgcrypt-1.8.3-4' and updated to:
'libgcrypt-1.8.5-4'.
After this, I got the "Unknown file format 'qcow'" error:
~~~
$ qemu-img create -f qcow /tmp/glance-unittest-images-5flalm7e.qcow 134217728
qemu-img: /tmp/glance-unittest-images-5flalm7e.qcow: Unknown file format
'qcow'
$ qemu-img create -f qcow2 /tmp/glance-unittest-images-5flalm7e.qcow 134217728
Formatting '/tmp/glance-unittest-images
[Yahoo-eng-team] [Bug 1391504] Re: Sample policies for Openstack
** 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/1391504 Title: Sample policies for Openstack Status in Cinder: In Progress Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): In Progress Bug description: Regarding OpenStack policies, in general, the described roles seem quite complicated, it is not clear which roles are appropriated for each user. For example, in many policies it is defined just a global admin role. We would like to clarify what are the role organizations, for example, cloud_admin is the role for the cloud managers, domain_admin is the role for the domain managers, project_admin for the project admin and project_member a member with a role in a project but with no admin permissions. In this way, it is clear for the cloud manager which capability is being given to a user. The idea is create a policy.cloudsample.json, where roles as cloud_admin project_admin, and project_member will be defined and some default permissions, making policies closer to the business reality. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1391504/+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 1391504] [NEW] Sample policies for Openstack
Public bug reported: Regarding OpenStack policies, in general, the described roles seem quite complicated, it is not clear which roles are appropriated for each user. For example, in many policies it is defined just a global admin role. We would like to clarify what are the role organizations, for example, cloud_admin is the role for the cloud managers, domain_admin is the role for the domain managers, project_admin for the project admin and project_member a member with a role in a project but with no admin permissions. In this way, it is clear for the cloud manager which capability is being given to a user. The idea is create a policy.cloudsample.json, where roles as cloud_admin project_admin, and project_member will be defined and some default permissions, making policies closer to the business reality. ** Affects: cinder Importance: Undecided Status: New ** Affects: glance Importance: Undecided Status: New ** Affects: keystone Importance: Undecided Status: New ** Affects: nova Importance: Undecided Status: New ** Tags: policy ** Project changed: keystone => glance ** Also affects: keystone Importance: Undecided Status: New ** Also affects: cinder Importance: Undecided Status: New ** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1391504 Title: Sample policies for Openstack Status in Cinder: New Status in OpenStack Image Registry and Delivery Service (Glance): New Status in OpenStack Identity (Keystone): New Status in OpenStack Compute (Nova): New Bug description: Regarding OpenStack policies, in general, the described roles seem quite complicated, it is not clear which roles are appropriated for each user. For example, in many policies it is defined just a global admin role. We would like to clarify what are the role organizations, for example, cloud_admin is the role for the cloud managers, domain_admin is the role for the domain managers, project_admin for the project admin and project_member a member with a role in a project but with no admin permissions. In this way, it is clear for the cloud manager which capability is being given to a user. The idea is create a policy.cloudsample.json, where roles as cloud_admin project_admin, and project_member will be defined and some default permissions, making policies closer to the business reality. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1391504/+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 1384377] [NEW] Policy rule position errors
Public bug reported: In the policy.v3cloudsample.json there is the rule "admin_or_owner" that is defined as "(rule:admin_required and domain_id:%(target.token.user.domain.id)s) or rule:owner", and the tests for it ( https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L7 ) , specially this keystone.tests.test_v3_auth.TestTokenRevokeSelfAndAdmin.test_user_revokes_own_token shows it's working as expected. The rule "admin_required" is defined only as "role:admin" ( https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L2 ), so I changed the rule "admin_or_owner" to "(role:admin and domain_id:%(target.token.user.domain.id)s) or rule:owner" and the test raises a error saying that the user has no permission to do the action. As it's the same rule, it wasn't suppose to raise errors. But it doesn't stop there, when I rearrange the rule order to be like this: "admin_or_owner": "rule:owner or (role:admin and domain_id:%(target.token.user.domain.id)s)" it works. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1384377 Title: Policy rule position errors Status in OpenStack Identity (Keystone): New Bug description: In the policy.v3cloudsample.json there is the rule "admin_or_owner" that is defined as "(rule:admin_required and domain_id:%(target.token.user.domain.id)s) or rule:owner", and the tests for it ( https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L7 ) , specially this keystone.tests.test_v3_auth.TestTokenRevokeSelfAndAdmin.test_user_revokes_own_token shows it's working as expected. The rule "admin_required" is defined only as "role:admin" ( https://github.com/openstack/keystone/blob/master/etc/policy.v3cloudsample.json#L2 ), so I changed the rule "admin_or_owner" to "(role:admin and domain_id:%(target.token.user.domain.id)s) or rule:owner" and the test raises a error saying that the user has no permission to do the action. As it's the same rule, it wasn't suppose to raise errors. But it doesn't stop there, when I rearrange the rule order to be like this: "admin_or_owner": "rule:owner or (role:admin and domain_id:%(target.token.user.domain.id)s)" it works. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1384377/+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 1376751] [NEW] Policy rule "context_is_admin" is checked instead of "admin_api"
Public bug reported: When trying to allow a user with role "domain_admin" to list Hypervisors ( "compute_extension:hypervisors": "rule:admin_api" ), I modified the rule "admin_api" to also accepts the new role ( "admin_api": "is_admin:True or role:domain_admin" ). After this I was still unable to list the hypervisors and got the error: "ERROR (Forbidden): User does not have admin privileges (HTTP 403) (Request-ID: req-11ba9712-adff-42fa-b1f2-90532c4a77f1)". After trying to modified the rule "context_is_admin" ( "context_is_admin": "role:admin or role:domain_admin") listing the hypervisors worked. The rule "admin_api" is not working as it should, maybe there is a hard-coded check on Nova code that only enforce a set of operations woth the rule "context_is_admin" ** Affects: nova Importance: Undecided Assignee: Sylvain Bauza (sylvain-bauza) 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/1376751 Title: Policy rule "context_is_admin" is checked instead of "admin_api" Status in OpenStack Compute (Nova): New Bug description: When trying to allow a user with role "domain_admin" to list Hypervisors ( "compute_extension:hypervisors": "rule:admin_api" ), I modified the rule "admin_api" to also accepts the new role ( "admin_api": "is_admin:True or role:domain_admin" ). After this I was still unable to list the hypervisors and got the error: "ERROR (Forbidden): User does not have admin privileges (HTTP 403) (Request-ID: req-11ba9712-adff-42fa-b1f2-90532c4a77f1)". After trying to modified the rule "context_is_admin" ( "context_is_admin": "role:admin or role:domain_admin") listing the hypervisors worked. The rule "admin_api" is not working as it should, maybe there is a hard-coded check on Nova code that only enforce a set of operations woth the rule "context_is_admin" To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1376751/+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
