Open Stack

But this procedure will force me to download all images in advance, which I
can not do.

I NEED the previous behavior, where Glance download the images by itself,
on demand.

How to do this with V2 ?

On 18 February 2016 at 01:47, Fei Long Wang <feilong at catalyst.net.nz> wrote:

> Glance v2 doesn't support 'location' anymore, now there are multi
> locations for image in V2. You can use 'glance location-add' after create
> the the image by 'glance image-create --file xxx'
>
>
> On 18/02/16 15:51, Martinx - ジェームズ wrote:
>
> Hey guys, any news about this?
>
> I want to use Glance v2 but, without --location that points to a URL and,
> for me, without it, it is impossible to use it (v2).
>
> So, any plans to bring back --location, I want to use v2 like this:
>
> --
> glance image-create --location
> http://uec-images.ubuntu.com/releases/14.04.3/release/ubuntu-14.04-server-cloudimg-amd64-disk1.img
> --name "Ubuntu 14.04.3 LTS - Trusty Tahr - 64-bit - Cloud Based Image"
> --visibility public --container-format bare --disk-format qcow2
> --
>
> But, "--location" isn't recognized anymore!
>
> Thanks!
> Thiago
>
>
> On 22 January 2014 at 14:30, Mark Washenberger <
> mark.washenberger at markwash.net> wrote:
>
>>
>>
>>
>> On Wed, Jan 22, 2014 at 1:05 AM, Public Mail < <kpublicmail at gmail.com>
>> kpublicmail at gmail.com> wrote:
>>
>>> Hi All,
>>>
>>>     I have two questions ...
>>>
>>>     1) Glance v1 APIs can take a --location argument when creating an
>>> image
>>>        but v2 APIs can't - bug or feature? (Details below)
>>>
>>
>> I'd call that a missing feature. I think we probably need a glance
>> image-location-add command somewhere in the client. But fair warning, this
>> is typically a role-restricted operation.
>>
>>
>>>
>>>     2) How should glanceclient (v2 commands) handle reserved attributes?
>>>         a) status quo: (Apparently) let the user set them but the server
>>>            will return "attribute is reserved" error.  Pros: No missing
>>>            functionality, no damage done.  Cons: Bad usability.
>>>         b) hard-code list of reserved attributes in client and don't
>>> expose
>>>            them to the user.
>>>             Pros: quick to implement.
>>>             Cons: Need to track reserved attributes in server
>>>                 implementation.
>>>         c) get-reserved words from schema downloaded from server (and
>>> don't
>>>            expose them to the user).
>>>             Pros: Don't need to track server implmentation.
>>>             Cons: Complex - reserved words can vary from command to
>>>                 command.
>>>
>>>       I personally favor (b) on the grounds that a client implementation
>>>       needs to closely understand server behaviour anyway so the sync-ing
>>>       of reserved attributes shouldn't be a big problem (*provided* the
>>>       list of reserved attributes is made available in the reference
>>>       documentation which doesn't seem to be the case currently).
>>>
>>
>>
>> We are in a bit of a bind with schemas--what's needed is schema resources
>> to represent each request and response, not just each resource. Because,
>> obviously, the things you can PATCH and POST are necessarily different than
>> the things you can GET in any service api. However, it is not clear to me
>> how we get from one schema per resource to one schema per request and
>> response in a backwards compatible way. So b) might be the only way to go.
>>
>>
>>
>>>
>>> So what does everybody think?
>>>
>>> <details>
>>> When using glance client's v1 interface I can image-create an image and
>>> specify the image file's location via the --location parameter.
>>> Alternatively I can image-create an empty image and then image-update the
>>> image's location to some url.
>>>
>>> However, when using the client's v2 commands I can neither image-create
>>> the
>>> file using the --location parameter, nor image-update the file later.
>>>
>>> When using image-create with --location, the client gives the following
>>> error (printed by warlock):
>>>
>>>   Unable to set 'locations' to '[u' <http://192.168.1.111/foo/bar%27>
>>> http://192.168.1.111/foo/bar']'
>>>
>>> This is because the schema dictates that the location should be an object
>>> of the form [{"url": "string", "metadata": object}, ...] but there is no
>>> way to specify such an object from the command line - I cannot specify a
>>> string like '{"url": "192.168.1.111/foo/bar", "metadata": {}}' for
>>> there is
>>> no conversion from command line strings to python dicts nor is there any
>>> conversion from a simple URL string to a suitable location object.
>>>
>>> If I modify glanceclient.v2.images.Controller.create to convert the
>>> locations parameter from a URL string to the desired object then the
>>> request goes through to the glance server where it fails with a 403 error
>>> (Attribute 'locations' is reserved).
>>>
>>> So is this discrepancy between V1 & V2 deliberate (a feature :)) or is
>>> it a
>>> bug?
>>> </details>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> --
> Cheers & Best regards,
> Fei Long Wang (王飞龙)
> --------------------------------------------------------------------------
> Senior Cloud Software Engineer
> Tel: +64-48032246
> Email: flwang at catalyst.net.nz
> Catalyst IT Limited
> Level 6, Catalyst House, 150 Willis Street, Wellington
> --------------------------------------------------------------------------
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160218/2b5ed2c5/attachment.html>