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 <[email protected]> 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 < > [email protected]> wrote: > >> >> >> >> On Wed, Jan 22, 2014 at 1:05 AM, Public Mail < <[email protected]> >> [email protected]> 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 >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?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: [email protected] > Catalyst IT Limited > Level 6, Catalyst House, 150 Willis Street, Wellington > -------------------------------------------------------------------------- > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
