Open Stack

On 11/01/16 15:01 +0000, stuart.mclaren at hp.com 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-items
>
>
> I 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160111/43d04a58/attachment.pgp>