[openstack-dev] [glance] Seeking FFE for "Support single disk image OVA/OVF package upload"
flavio at redhat.com
Fri Jan 8 18:43:46 UTC 2016
On 08/01/16 17:03 +0000, stuart.mclaren at hp.com wrote:
>>Hello Glance Team!
>> Hope you had a wonderful vacation and wishing you health and happiness for 2016.
>>Would very much appreciate your considering https://review.openstack.org/194868 for a feature freeze exception.
>>I believe the spec is pretty solid, and we can deliver on the implementation by M-2. But were unable to get enough core
>>Votes during the holiday season.
>>-------------- next part --------------
>>An HTML attachment was scrubbed...
>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:
>(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 (see work
>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 is done. In addition
to this work, there's also the requirement to make the task executable
only by admins. This has been explicitly mentioned in the OVF spec and
we need to test/enforce that the code respects this.
Note that we're evaluating an exception for the *spec* and not the
code. Therefore, using the current version of the code as a reference
rather than what's in the spec is probably not ideal.
One final note that I'd like to make. The *task class/implementation*
has nothing to do with the API. It can be functionally tested without
API calls and it can be disabled. The fact that you can run it using
the old task API doesn't mean that you should or that it's what we're
recomending. The old task API is taking its first step down the
deprecation path and it'll take some time for that to happen. This, I
insist, does not mean the team is encouraging such API.
The OVF work was delayed in Kilo. We also blocked in Liberty because
we knew the upload path needed to be refectored. In Mitaka we blocked
it until the very end of the spec review process because we wanted to
make sure it wouldn't interfeer with the priorities of the cycle. Now
that we know that, I can't hardly think of a reason to not let this
through. One motivation is that I don't think it'll confuse folks as
we're clearly saying (in code, communications and whatnot) that the
old task API should go away.
Sure, some ppl don't listen and the world isn't perfect but there are
trade offs and those are the ones we're evaluating.
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: not available
More information about the OpenStack-dev