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

2016-01-11 Thread stuart . mclaren 

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: 



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



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

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

2016-01-11 Thread Flavio Percoco 

On 11/01/16 15:01 +, stuart.mcla...@hp.com wrote:

An HTML attachment was scrubbed...
URL: 



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


signature.asc
Description: PGP signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-01-08 Thread Flavio Percoco 

On 08/01/16 17:03 +, stuart.mcla...@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.



  Regards



  Malini




-- next part --
An HTML attachment was scrubbed...
URL: 



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: openstack-dev-requ...@lists.openstack.org?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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-01-08 Thread stuart . mclaren 



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: 



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?

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?

-Stuart

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2016-01-04 Thread Bhandaru, Malini K 
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


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev