registered images is queued, not showing up
Hi there,
I've configured Nova to use Glance. Everything is working fine except when I call uec-publish-image or euca-register on the image, the resulting image is not showing up by euca-describe-
I checked the file system and made sure
1. The images are in place at /var/lib/
2. The glance.sqlite in the images table, the state=queued for all registered images. They need to be active to show up under euca-describe-
I am running Ubuntu-10.10 with glance-
Is this a bug? The earlier version of glance-
Thanks.
Shi
Question information
- Language:
- English Edit question
- Status:
- Answered
- For:
- Glance Edit question
- Assignee:
- No assignee Edit question
- Last query:
- Last reply:
Related FAQ:
None Link to a FAQ
Revision history for this message
|
#1 |
Actually, if I can guess its ID, it is shown as available like
seki@OSCC:/tmp$ euca-describe-
IMAGE ami-00000008 win8/win08-
And I can run instance out of it
seki@OSCC:/tmp$ euca-run-instances ami-00000008
RESERVATION r-nr8zt1pa test default
INSTANCE i-00000026 ami-00000008 scheduling None (test, None) 0 m1.small 2011-04-
It is just not showing up automatically under the pure euca-describe-
Revision history for this message
|
#2 |
After further investigation, this is the exact same issue I am having (see https:/
Cheers,
Graham
Revision history for this message
|
#3 |
I can duplicate this. I am still investigating why a new version of glance may have caused this to manifest itself, but from what I can tell, the issue is that the s3 proxy code sets image['status'] to queued, but when it updates the status, it is actually updating image['
From nova/image/s3.py (lines 153-157):
metadata.
This updates the images table and sets the status to queued. Then later (in various places, but line 200 is where it is set to available):
with open(unz_filename) as image_file:
Then finally the image is returned on line 207.
Checking the DB confirms these findings:
mysql> select * from image_properties where image_id = 4;
+----+-
| id | image_id | name | value | created_at | updated_at | deleted_at | deleted |
+----+-
| 21 | 4 | architecture | x86_64 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
| 18 | 4 | image_location | uec-publish-
| 19 | 4 | image_state | available | 2011-04-28 16:10:20 | 2011-04-28 16:10:44 | NULL | 0 |
| 17 | 4 | kernel_id | 3 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
| 20 | 4 | project_id | sandbox | 2011-04-28 16:10:20 | NULL | NULL | 0 |
+----+-
5 rows in set (0.00 sec)
mysql> select * from images where id = 4;
+----+-
| id | name | size | status | is_public | location | created_at | updated_at | deleted_at | deleted | disk_format | container_format | checksum |
+----+-
| 4 | NULL | 1476395008 | queued | 1 | file://
+----+-
1 row in set (0.00 sec)
Running:
update images set status = 'active' where id = 4;
or alteratively
update images set status = 'active' where status = 'queued'
would do it as well, but make sure that you are not actively uploading any images when you run that or you may end up breaking something :-)
The above should be a work to fix it, and hopefully a patch will be released soon :-)
Revision history for this message
|
#4 |
I can duplicate this. I am still investigating why a new version of glance may have caused this to manifest itself, but from what I can tell, the issue is that the s3 proxy code sets image['status'] to queued, but when it updates the status, it is actually updating image['
From nova/image/s3.py (lines 153-157):
metadata.
This updates the images table and sets the status to queued. Then later (in various places, but line 200 is where it is set to available):
with open(unz_filename) as image_file:
Then finally the image is returned on line 207.
Checking the DB confirms these findings:
mysql> select * from image_properties where image_id = 4;
+----+-
| id | image_id | name | value | created_at | updated_at | deleted_at | deleted |
+----+-
| 21 | 4 | architecture | x86_64 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
| 18 | 4 | image_location | uec-publish-
| 19 | 4 | image_state | available | 2011-04-28 16:10:20 | 2011-04-28 16:10:44 | NULL | 0 |
| 17 | 4 | kernel_id | 3 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
| 20 | 4 | project_id | sandbox | 2011-04-28 16:10:20 | NULL | NULL | 0 |
+----+-
5 rows in set (0.00 sec)
mysql> select * from images where id = 4;
+----+-
| id | name | size | status | is_public | location | created_at | updated_at | deleted_at | deleted | disk_format | container_format | checksum |
+----+-
| 4 | NULL | 1476395008 | queued | 1 | file://
+----+-
1 row in set (0.00 sec)
Running:
update images set status = 'active' where id = 4;
or alteratively
update images set status = 'active' where status = 'queued'
would do it as well, but make sure that you are not actively uploading any images when you run that or you may end up breaking something :-)
The above should be a work to fix it, and hopefully a patch will be released soon :-)
Revision history for this message
|
#5 |
In glance change #125 in glance/
Thanks for the workaround, the fix should be pretty easy I imagine
Cheers,
Graham
On Apr 28, 2011, at 12:10 PM, Kevin Bringard <email address hidden> wrote:
> Question #154460 on Glance changed:
> https:/
>
> Status: Open => Answered
>
> Kevin Bringard proposed the following answer:
> I can duplicate this. I am still investigating why a new version of
> glance may have caused this to manifest itself, but from what I can
> tell, the issue is that the s3 proxy code sets image['status'] to
> queued, but when it updates the status, it is actually updating
> image['
>
>> From nova/image/s3.py (lines 153-157):
>
>
> metadata.
> 'container_format': image_format,
> 'status': 'queued',
> 'is_public': True,
> 'properties': properties})
>
> This updates the images table and sets the status to queued. Then later
> (in various places, but line 200 is where it is set to available):
>
> with open(unz_filename) as image_file:
> self.service.
> metadata[
> self.service.
>
>
> Then finally the image is returned on line 207.
>
> Checking the DB confirms these findings:
>
>
> mysql> select * from image_properties where image_id = 4;
> +----+-
> | id | image_id | name | value | created_at | updated_at | deleted_at | deleted |
> +----+-
> | 21 | 4 | architecture | x86_64 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
> | 18 | 4 | image_location | uec-publish-
> | 19 | 4 | image_state | available | 2011-04-28 16:10:20 | 2011-04-28 16:10:44 | NULL | 0 |
> | 17 | 4 | kernel_id | 3 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
> | 20 | 4 | project_id | sandbox | 2011-04-28 16:10:20 | NULL | NULL | 0 |
> +----+-
> 5 rows in set (0.00 sec)
>
>
> mysql> select * from images where id = 4;
> +----+-
> | id | name | size | status | is_public | location | created_at | updated_at | deleted_at | deleted | disk_format | container_format | checksum |
> +----+-
> | 4 | NULL | 1476395008 | queued | 1 | file://
> +----+-
> 1 row in set (0.00 sec)
>
> Running:
>
> update images set status = 'active' where id = 4;
>
> or alteratively
>
> update images set status = 'active' where status = 'queued'
>
> would do it as well, but make sure that you are not actively uploading
> any images when you run that or you may end up breaking something :-)
>
> The above should be a work to fix it, and hopefully a patch will be
> released soon :-)
>
> --
> You received this question notification because you are a direct
> subscriber of the question.
Revision history for this message
|
#6 |
Interesting. The filter might stop non-available images from showing up, but images that successfully register should be changed to active. This makes me think that some part of the decrypting process is actually failing. Unless there is some reason that the filter would stop the update code in s3.py from working.
Vish
On Apr 28, 2011, at 10:39 AM, Graham Hemingway wrote:
> Question #154460 on Glance changed:
> https:/
>
> Graham Hemingway proposed the following answer:
> In glance change #125 in glance/
> on status='active' was added. This would do it.
>
> Thanks for the workaround, the fix should be pretty easy I imagine
>
> Cheers,
> Graham
>
>
> On Apr 28, 2011, at 12:10 PM, Kevin Bringard
> <email address hidden> wrote:
>
>> Question #154460 on Glance changed:
>> https:/
>>
>> Status: Open => Answered
>>
>> Kevin Bringard proposed the following answer:
>> I can duplicate this. I am still investigating why a new version of
>> glance may have caused this to manifest itself, but from what I can
>> tell, the issue is that the s3 proxy code sets image['status'] to
>> queued, but when it updates the status, it is actually updating
>> image['
>>
>>> From nova/image/s3.py (lines 153-157):
>>
>>
>> metadata.
>> 'container_format': image_format,
>> 'status': 'queued',
>> 'is_public': True,
>> 'properties': properties})
>>
>> This updates the images table and sets the status to queued. Then later
>> (in various places, but line 200 is where it is set to available):
>>
>> with open(unz_filename) as image_file:
>> self.service.
>> metadata[
>> self.service.
>>
>>
>> Then finally the image is returned on line 207.
>>
>> Checking the DB confirms these findings:
>>
>>
>> mysql> select * from image_properties where image_id = 4;
>> +----+-
>> | id | image_id | name | value | created_at | updated_at | deleted_at | deleted |
>> +----+-
>> | 21 | 4 | architecture | x86_64 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
>> | 18 | 4 | image_location | uec-publish-
>> | 19 | 4 | image_state | available | 2011-04-28 16:10:20 | 2011-04-28 16:10:44 | NULL | 0 |
>> | 17 | 4 | kernel_id | 3 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
>> | 20 | 4 | project_id | sandbox | 2011-04-28 16:10:20 | NULL | NULL | 0 |
>> +----+-
>> 5 rows in set (0.00 sec)
>>
>>
>> mysql> select * from images where id = 4;
>> +----+-
>> | id | name | size | status | is_public | location | created_at | updated_at | deleted_at | deleted | disk_format | container_format | checksum |
>> +----+-
>> | 4 | NULL | 1476395008 | queued | 1 | file://
>> +----+-
>> 1 row in set (0.00 sec)
>>
>> Running:
>>
>> update images set status = 'active' where id = 4;
>>
>> or alteratively
>>
>> update images set status = 'active' where status = 'queued'
>>
>> would do it as well, but make sure that you are not actively uploading
>> any images when you run that or you may end up breaking something :-)
>>
>> The above should be a work to fix it, and hopefully a patch will be
>> released soon :-)
>>
>> --
>> You received this question notification because you are a direct
>> subscriber of the question.
>
> --
> You received this question notification because you are a member of
> Glance Core, which is an answer contact for Glance.
Revision history for this message
|
#7 |
I just tried setting the Glance DB entries to 'active' for my two images, but both images fail to create good instances. From Vish's comment it makes me think they might still be encrypted. I am continuing to explore.
Cheers,
Graham
On Apr 28, 2011, at 1:45 PM, Vish Ishaya <email address hidden> wrote:
> Question #154460 on Glance changed:
> https:/
>
> Vish Ishaya proposed the following answer:
> Interesting. The filter might stop non-available images from showing
> up, but images that successfully register should be changed to active.
> This makes me think that some part of the decrypting process is actually
> failing. Unless there is some reason that the filter would stop the
> update code in s3.py from working.
>
> Vish
>
> On Apr 28, 2011, at 10:39 AM, Graham Hemingway wrote:
>
>> Question #154460 on Glance changed:
>> https:/
>>
>> Graham Hemingway proposed the following answer:
>> In glance change #125 in glance/
>> on status='active' was added. This would do it.
>>
>> Thanks for the workaround, the fix should be pretty easy I imagine
>>
>> Cheers,
>> Graham
>>
>>
>> On Apr 28, 2011, at 12:10 PM, Kevin Bringard
>> <email address hidden> wrote:
>>
>>> Question #154460 on Glance changed:
>>> https:/
>>>
>>> Status: Open => Answered
>>>
>>> Kevin Bringard proposed the following answer:
>>> I can duplicate this. I am still investigating why a new version of
>>> glance may have caused this to manifest itself, but from what I can
>>> tell, the issue is that the s3 proxy code sets image['status'] to
>>> queued, but when it updates the status, it is actually updating
>>> image['
>>>
>>>> From nova/image/s3.py (lines 153-157):
>>>
>>>
>>> metadata.
>>> 'container_format': image_format,
>>> 'status': 'queued',
>>> 'is_public': True,
>>> 'properties': properties})
>>>
>>> This updates the images table and sets the status to queued. Then later
>>> (in various places, but line 200 is where it is set to available):
>>>
>>> with open(unz_filename) as image_file:
>>> self.service.
>>> metadata[
>>> self.service.
>>>
>>>
>>> Then finally the image is returned on line 207.
>>>
>>> Checking the DB confirms these findings:
>>>
>>>
>>> mysql> select * from image_properties where image_id = 4;
>>> +----+-
>>> | id | image_id | name | value | created_at | updated_at | deleted_at | deleted |
>>> +----+-
>>> | 21 | 4 | architecture | x86_64 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
>>> | 18 | 4 | image_location | uec-publish-
>>> | 19 | 4 | image_state | available | 2011-04-28 16:10:20 | 2011-04-28 16:10:44 | NULL | 0 |
>>> | 17 | 4 | kernel_id | 3 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
>>> | 20 | 4 | project_id | sandbox | 2011-04-28 16:10:20 | NULL | NULL | 0 |
>>> +----+-
>>> 5 rows in set (0.00 sec)
>>>
>>>
>>> mysql> select * from images where id = 4;
>>> +----+-
>>> | id | name | size | status | is_public | location | created_at | updated_at | deleted_at | deleted | disk_format | container_format | checksum |
>>> +----+-
>>> | 4 | NULL | 1476395008 | queued | 1 | file://
>>> +----+-
>>> 1 row in set (0.00 sec)
>>>
>>> Running:
>>>
>>> update images set status = 'active' where id = 4;
>>>
>>> or alteratively
>>>
>>> update images set status = 'active' where status = 'queued'
>>>
>>> would do it as well, but make sure that you are not actively uploading
>>> any images when you run that or you may end up breaking something :-)
>>>
>>> The above should be a work to fix it, and hopefully a patch will be
>>> released soon :-)
>>>
>>> --
>>> You received this question notification because you are a direct
>>> subscriber of the question.
>>
>> --
>> You received this question notification because you are a member of
>> Glance Core, which is an answer contact for Glance.
>
> --
> You received this question notification because you are a direct
> subscriber of the question.
Revision history for this message
|
#8 |
I set the db entry to active and it worked for me.
Revision history for this message
|
#9 |
After checking the code, it appears that the code doesn't switch the state to active like i thought it did. I suppose we could just create the image (in s3.py) in the active state instead of the queued state.
Vish
On Apr 28, 2011, at 10:39 AM, Graham Hemingway wrote:
> Question #154460 on Glance changed:
> https:/
>
> Graham Hemingway proposed the following answer:
> In glance change #125 in glance/
> on status='active' was added. This would do it.
>
> Thanks for the workaround, the fix should be pretty easy I imagine
>
> Cheers,
> Graham
>
>
> On Apr 28, 2011, at 12:10 PM, Kevin Bringard
> <email address hidden> wrote:
>
>> Question #154460 on Glance changed:
>> https:/
>>
>> Status: Open => Answered
>>
>> Kevin Bringard proposed the following answer:
>> I can duplicate this. I am still investigating why a new version of
>> glance may have caused this to manifest itself, but from what I can
>> tell, the issue is that the s3 proxy code sets image['status'] to
>> queued, but when it updates the status, it is actually updating
>> image['
>>
>>> From nova/image/s3.py (lines 153-157):
>>
>>
>> metadata.
>> 'container_format': image_format,
>> 'status': 'queued',
>> 'is_public': True,
>> 'properties': properties})
>>
>> This updates the images table and sets the status to queued. Then later
>> (in various places, but line 200 is where it is set to available):
>>
>> with open(unz_filename) as image_file:
>> self.service.
>> metadata[
>> self.service.
>>
>>
>> Then finally the image is returned on line 207.
>>
>> Checking the DB confirms these findings:
>>
>>
>> mysql> select * from image_properties where image_id = 4;
>> +----+-
>> | id | image_id | name | value | created_at | updated_at | deleted_at | deleted |
>> +----+-
>> | 21 | 4 | architecture | x86_64 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
>> | 18 | 4 | image_location | uec-publish-
>> | 19 | 4 | image_state | available | 2011-04-28 16:10:20 | 2011-04-28 16:10:44 | NULL | 0 |
>> | 17 | 4 | kernel_id | 3 | 2011-04-28 16:10:20 | NULL | NULL | 0 |
>> | 20 | 4 | project_id | sandbox | 2011-04-28 16:10:20 | NULL | NULL | 0 |
>> +----+-
>> 5 rows in set (0.00 sec)
>>
>>
>> mysql> select * from images where id = 4;
>> +----+-
>> | id | name | size | status | is_public | location | created_at | updated_at | deleted_at | deleted | disk_format | container_format | checksum |
>> +----+-
>> | 4 | NULL | 1476395008 | queued | 1 | file://
>> +----+-
>> 1 row in set (0.00 sec)
>>
>> Running:
>>
>> update images set status = 'active' where id = 4;
>>
>> or alteratively
>>
>> update images set status = 'active' where status = 'queued'
>>
>> would do it as well, but make sure that you are not actively uploading
>> any images when you run that or you may end up breaking something :-)
>>
>> The above should be a work to fix it, and hopefully a patch will be
>> released soon :-)
>>
>> --
>> You received this question notification because you are a direct
>> subscriber of the question.
>
> --
> You received this question notification because you are a member of
> Glance Core, which is an answer contact for Glance.
Revision history for this message
|
#10 |
Should we file a bug to get this fix in?
Thanks. G
Revision history for this message
|
#11 |
Can you help with this problem?
Provide an answer of your own, or ask Shi Jin for more information if necessary.