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] > <mailto:[email protected]>> wrote: > > > > > On Wed, Jan 22, 2014 at 1:05 AM, Public Mail > <[email protected] <mailto:[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' > <http://192.168.1.111/foo/bar%27>]' > > 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 > <http://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] > <mailto:[email protected]> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > <mailto:[email protected]> > 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 -- 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
