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]> > 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 >> [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:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
