On 08/01/16 17:03 +0000, [email protected] 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 coreVotes during the holiday season.RegardsMalini-------------- 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
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. 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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-- @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
