Open Stack

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
> <mailto:mark.washenberger at markwash.net>> wrote:
>
>
>
>
>     On Wed, Jan 22, 2014 at 1:05 AM, Public Mail
>     <kpublicmail at gmail.com <mailto: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'
>         <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
>         OpenStack-dev at lists.openstack.org
>         <mailto: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
>     <mailto: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: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: flwang at catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-------------------------------------------------------------------------- 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160218/aac4daf3/attachment.html>