Ask Your Question
4

unable to create new image

asked 2014-11-24 16:19:52 -0500

frayedknot gravatar image

updated 2014-11-25 13:31:36 -0500

Hi,

I've followed the RDO quick start on top of CentOS 7 and I've now moved on to "Running an instance" which is linked at the bottom of the RDO quick start (I need 10 karma points in order to post links, so I apologize that I don't have any).

Step 4 fails for me and a little red box comes up with "Unable to create new image". I also tried just using a local .iso file to the same result.

Being new to this, I'm unsure of how troubleshoot openstack. I've looked in /var/log/horizon/horizon.log, but there isn't much for detail.

2014-11-22 04:04:59,428 18080 WARNING horizon.exceptions Recoverable error: <html>
 <head>
  <title>403 Forbidden</title>
 </head>
 <body>
  <h1>403 Forbidden</h1>
  Access was denied to this resource.<br /><br />

 </body>
</html> (HTTP 403)

I also don't see anything in the glance logs. I'm curious where I should be looking for more debugging information and if anyone else as ran into this issue.

Thanks in advance.


UPDATE 2: Through the Identify>Projects interface as the admin user, I added the admin role to the demo user. It's default value is _member_. Then, logging in as the demo user, I was able to create an image. So this must be a permissions issue with the _member_ role?

Is there a way I can see/define what roles can or cannot do? Is there a hole in the quick start documentation? I assume not, since I'm the only one having this issue.


UPDATE 1: I updated the config to enable debug. Here's a snippet of the api.log after I click 'Create Image'. I don't see any errors.

2014-11-25 11:00:26.825 2201 DEBUG glance.api.middleware.version_negotiation [-] Determining version of request: POST /v1/images Accept: */* process_request /usr/lib/python2.7/site-packages/glance/api/middleware/version_negotiation.py:44
2014-11-25 11:00:26.826 2201 DEBUG glance.api.middleware.version_negotiation [-] Using url versioning process_request /usr/lib/python2.7/site-packages/glance/api/middleware/version_negotiation.py:57
2014-11-25 11:00:26.826 2201 DEBUG glance.api.middleware.version_negotiation [-] Matched version: v1 process_request /usr/lib/python2.7/site-packages/glance/api/middleware/version_negotiation.py:69
2014-11-25 11:00:26.826 2201 DEBUG glance.api.middleware.version_negotiation [-] new path /v1/images process_request /usr/lib/python2.7/site-packages/glance/api/middleware/version_negotiation.py:70
2014-11-25 11:00:26.826 2201 DEBUG keystonemiddleware.auth_token [-] Removing headers from request environment: X-Service-Catalog,X-Identity-Status,X-Roles,X-Service-Roles,X-Domain-Name,X-Service-Domain-Name,X-Project-Id,X-Service-Project-Id,X-Project-Domain-Name,X-Service-Project-Domain-Name,X-User-Id,X-Service-User-Id,X-User-Name,X-Service-User-Name,X-Project-Name,X-Service-Project-Name,X-User-Domain-Id,X-Service-User-Domain-Id,X-Domain-Id,X-Service-Domain-Id,X-User-Domain-Name,X-Service-User-Domain-Name,X-Project-Domain-Id,X-Service-Project-Domain-Id,X-Role,X-User,X-Tenant-Name,X-Tenant-Id,X-Tenant _remove_auth_headers /usr/lib/python2.7/site-packages/keystonemiddleware/auth_token.py:780
2014-11-25 11:00:26.826 2201 DEBUG keystonemiddleware.auth_token [-] Authenticating user token __call__ /usr/lib/python2.7/site-packages/keystonemiddleware/auth_token.py:708
2014-11-25 11:00:26.830 2201 DEBUG keystonemiddleware.auth_token [-] Returning cached token _cache_get /usr/lib/python2.7/site-packages/keystonemiddleware/auth_token.py ...
(more)
edit retag flag offensive close merge delete

Comments

2

You could enable the debug logging level in /etc/glance/glance-api.conf. After that it should be possible to grep the glance logs for ERROR or TRACE . When you post the result of this grep one can help debugging. Perhaps you ran into this: https://bugs.launchpad.net/horizon/+b...

Markus Zoeller gravatar imageMarkus Zoeller ( 2014-11-25 02:49:39 -0500 )edit

I've updated my question with output from the log with debug enabled.

frayedknot gravatar imagefrayedknot ( 2014-11-25 11:01:45 -0500 )edit

5 answers

Sort by ยป oldest newest most voted
1

answered 2014-11-30 11:29:53 -0500

Stuart gravatar image

I am also experiencing this issue and can confirm that the "UPDATE 2:" entry for modifying the role of the demo user has worked for me.

Maybe another step needs to be added to the documentation?

edit flag offensive delete link more
1

answered 2014-11-24 22:46:55 -0500

cmyster gravatar image

Hi, I have also followed the same steps but it worked for me. Try to do that as the admin user and see if that helps. Also search the internet for cirros-0.3.3-x86_64-disk.img and try testing with it as it is much smaller then a Fedora image. Define it as a qcow2 image and see if you can create it.

edit flag offensive delete link more

Comments

Logging in as admin allows me to create images. I was able to create cirros as you suggested along with a local .iso.

I still cannot create the cirros image as the demo user. I'm investigating mzoellers comments now.

frayedknot gravatar imagefrayedknot ( 2014-11-25 10:06:56 -0500 )edit
1

answered 2014-11-25 13:40:38 -0500

echiu gravatar image

You can set property protection to control who has permissions to perform glance actions. The demo user may need to be granted permission to create new images.

For more details, see documentation on property protections http://docs.openstack.org/developer/g...

edit flag offensive delete link more
0

answered 2014-11-30 14:12:17 -0500

dbaxps gravatar image

updated 2014-11-30 14:14:08 -0500

Source keystonerc_admin and run ( for instance for F20 qcow2 image ):-

[root@juno1 ~(keystone_admin)]# [root@juno1 ~(keystone_admin)]#  glance image-create --name 'Fedora 20 x86_64' --disk-format qcow2 --container-format bare --is-public true  --copy-from http://cloud.fedoraproject.org/fedora-20.x86_64.qcow2
+------------------+--------------------------------------+
| Property         | Value                                |
+------------------+--------------------------------------+
| checksum         | None                                 |
| container_format | bare                                 |
| created_at       | 2014-11-30T20:10:38                  |
| deleted          | False                                |
| deleted_at       | None                                 |
| disk_format      | qcow2                                |
| id               | 1929b23f-887b-4e68-b2af-172d2683056e |
| is_public        | True                                 |
| min_disk         | 0                                    |
| min_ram          | 0                                    |
| name             | Fedora 20 x86_64                     |
| owner            | 2561f253faca48399d0cc77886574e1d     |
| protected        | False                                |
| size             | 210829312                            |
| status           | queued                               |
| updated_at       | 2014-11-30T20:10:38                  |
| virtual_size     | None                                 |
+------------------+--------------------------------------+

[root@juno1 ~(keystone_admin)]# glance image-list | grep " Fedora 20 x86_64"
| 1929b23f-887b-4e68-b2af-172d2683056e | Fedora 20 x86_64                | qcow2       | bare             | 210829312   | active |

Then login as as admin go to Images and make image Public

edit flag offensive delete link more
0

answered 2017-07-25 12:47:12 -0500

This is a few years late - but I wanted to share my experience:

I was having a similar issue in Packstack for the Ocata release working through the Horizon interface - _member_ user could not create an image. Project-level admin and Cloud-level admin could create the image successfully, though. I shared the same suspicion as the original poster - this is a permissions issue, but I could not find any hints in the logs.

Based on dbaxps's comment, I retried as the _member_ user, but this time with the visibility set to "Private" - this worked. It appears the issue is that the _member_ user cannot create public images. This may be by design, as the _member_ user can create a network, but cannot make it external - only the admin-level users can do this.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

2 followers

Stats

Asked: 2014-11-24 16:18:04 -0500

Seen: 7,075 times

Last updated: Nov 30 '14