Open Stack

On Wed, Jan 22, 2014 at 1:05 AM, Public Mail <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']'
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140122/88347f6f/attachment.html>