Open Stack

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>
> 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
>>
>
>
> _______________________________________________
> 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/20160218/bc529707/attachment.html>