[openstack-dev] [glance] Seeking FFE for "Support single disk image OVA/OVF package upload"

stuart.mclaren at hp.com stuart.mclaren at hp.com
Mon Jan 11 15:01:32 UTC 2016

>>> 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.
>>>               Regards
>>>               Malini
>>> -------------- next part --------------
>>> 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.

>> 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.)

> 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.
> [0] https://bugs.launchpad.net/glance/+bug/1527716
> Cheers,
> Flavio
>> -Stuart

More information about the OpenStack-dev mailing list