On 11/01/16 15:01 +0000, [email protected] wrote:
An HTML attachment was scrubbed... URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160104/157ebe90/attachment.html>I downloaded the patch which implements the spec (https://review.openstack.org/#/c/214810):I can make this REST API call to perform OVA import: http://paste.openstack.org/show/483332/ (it exercises the new OVA extract code path). There's a parallel effort in the project to provide 'official' (Defcore) APIs for image upload/conversion. What will be the advantage of having two different REST API calls (a 'tasks' based one and a DefCore one) for importing OVAs?As you mentioned above, the team is working on refactoring the image import process for Glance. The solution has different requirements and dependencies. One of those dependencies is making the existing task API admin only to then be able to deprecate it in the future. This has been discussed several times at the summit, in meetings and, to make sure it's clear to everyone (apparently it isn't) it's also been made of the spec of the refactor you mentioned[0] (see work items). [0] https://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html#work-itemsI understand we're aiming to retire the tasks API and that this call is intended to be admin only. I guess what I'd like to get a handle on is this: In the future, if a user asks "Why did my OVA API call fail?", we'll need to ask "Well, which OVA API did you use?" At that level there is a duplication -- something we'd generally try to avoid. If we're going to have that duplication I'd just like to understand why. For example, is it because we want the functionality exposed sooner? Or is it that the ability to trigger the new functionality via a /tasks call is a side-effect of the task implementation (one we don't really want in this case) and it would be too much effort to change it.
Definitely not the former. The later seems to be more accurate although I would add to it the fact we're deactivating this API.
It seems to be possible to successfully make the above API call whether you're admin or not and whether the server has the patch applied or not. Is that expected?You'll be able to run that request until this[0] is done.The current implementation hard codes that the OVA functionality is admin only. But the call still "succeeds" as a non-admin (creates an active image) because it re-uses the 'import' task type (ie we've an overloaded API). That means that if you're admin the API is ambiguous (knowing the request and response is not enough to know what actually happened). That may only be the current implementation though, and may not be what the spec intended. (Let's follow this bit up on the spec.)
The call that succeeds is the *image* import, which is not really the same as the *OVA* import task. This is exactly why I've been trying so hard to separate the current task HTTP API from the task engine. They are unrelated and we discussing this now is not really useful because that task HTTP API is going to go away and ppl shouldn't be using it to begin with. Flavio -- @flaper87 Flavio Percoco
signature.asc
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
