The ability to add an external image was dropped when I removed the concept of
image locations. I wanted to rethink how locations worked and didn't realize
how much I was actually removing! 'copy_from' just hasn't been fit into the
spec yet. I want both of the features to be exposed through the API, but I want
it done cleanly. This is something that we will figure out as we implement the
API, as there isn't a perfect solution right now. We definitely won't be
releasing the v2 API without these features!
Waldon
On Apr 10, 2012, at 6:21 AM, Eoghan Glynn wrote:
>
>
>> APPENDIX B: Outstanding issues
>> ...
>> 2) How do we fit the existing 'copy_from' functionality in?
>
>
> Is the v2 API retaining some equivalent of the existing
> x-image-meta-location header, to allow an externally-stored
> image be registered with glance?
>
> e.g. via an image field specified on create or update:
>
> POST /images HTTP/1.1
> {"external-location": "s3://access:sec...@s3.amzonaws.com/image", ...}
>
> or:
>
> PUT /images/<IMAGE_ID> HTTP/1.1
> {"external-location": "s3://access:sec...@s3.amzonaws.com/image", ...}
>
> If so, the most straight-forward approach for copy-from would be to
> follow a similar pattern with an image field such as:
>
> POST /images HTTP/1.1
> {"copy-from": "s3://access:sec...@s3.amzonaws.com/image", ...}
>
> ... etc.
>
> Cheers,
> Eoghan
>
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
