openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

On Jan 14, 2013, at 10:15 AM, Antonio Messina <antonio.s.messina@xxxxxxxxx> wrote:

> 
> On Mon, Jan 14, 2013 at 7:07 PM, Vishvananda Ishaya <vishvananda@xxxxxxxxx> wrote:
> 
> On Jan 14, 2013, at 9:28 AM, Antonio Messina <antonio.s.messina@xxxxxxxxx> wrote:
> 
>> On Mon, Jan 14, 2013 at 6:18 PM, Vishvananda Ishaya <vishvananda@xxxxxxxxx> wrote:
>> 
>> On Jan 14, 2013, at 7:49 AM, Jay Pipes <jaypipes@xxxxxxxxx> wrote:
>> 
>> >
>> > There is an integer key in the s3_images table that stores the map
>> > between the UUID and the AMI image id:
>> >
>> > https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/models.py#L964
>> >
>> > Not sure this is available via Horizon... sorry.
>> 
>> Correct. Here are some options:
>> 
>> a) query the db directly for the mapping
>> 
>> b) write an api extension to nova that exposes the mapping
>> 
>> c) write an external utility that syncs the info from the nova db into glance metadata
>> 
>> d) modify horizon to list images through the ec2 api instead of glance
>> 
>> I guess d) depends on b), since  we cannot assume horizon is running on the same machine as the nova-api service.
>> 
> 
> Not really. The ec2 api exposes ec2_style ids instead of uuids. It seems better to just provide one view of ids to your users. If you are suggesting they use the ec2 api then the uuids may not be needed.
> 
> I just misread: instead of d), I've read something like 
> 
>     e) modify horizon to list ec2 images id together with glance uuid
> 
> I will try to better explain the issue: 
> 
> I want my users to be able to customize some of the images already present on our cloud by creating snapshots. Then, they should be able to use our software (which uses EC2 api) to run their jobs. Our software is non-interactive, so I can't print a list from which the user can chose the correct image, the user must write the id on a configuration file.
> 
> I thing d) or e) would be fine, but d) will make our use case hard to apply to other clouds, while if OpenStack would accept a patch for e) we could be able to use other clouds as well...

Understood. An api extension to get the mapping seems perfectly reasonable.

Vish