Open Stack

On 14/09/15 19:06 +0200, Monty Taylor wrote:
>On 09/14/2015 02:41 PM, Flavio Percoco wrote:
>>On 14/09/15 08:10 -0400, Doug Hellmann wrote:
[snip]
>>>The task API is also not widely deployed, so its adoption for DefCore
>>>is problematic. If we provide a clear technical direction that this
>>>API is preferred, that may overcome the lack of adoption, but the
>>>current task API seems to have technical issues that make it
>>>fundamentally unsuitable for DefCore consideration. While the task
>>>API addresses the problem of a denial of service, and includes
>>>useful features such as processing of the image during import, it
>>>is not strongly enough defined in its current form to be interoperable.
>>>Because it's a generic API, the caller must know how to fully
>>>construct each task, and know what task types are supported in the
>>>first place. There is only one "import" task type supported in the
>>>Glance code repository right now, but it is not clear that "import"
>>>always uses the same arguments, or interprets them in the same way.
>>>For example, the upstream documentation [1] describes a task that
>>>appears to use a URL as source, while the Rackspace documentation [2]
>>>describes a task that appears to take a swift storage location.
>>>I wasn't able to find JSONSchema validation for the "input" blob
>>>portion of the task in the code [3], though that may happen down
>>>inside the task implementation itself somewhere.
>>
>>
>>The above sounds pretty accurate as there's currently just 1 flow that
>>can be triggered (the import flow) and that accepts an input, which is
>>a json. As I mentioned above, I don't believe tasks should be part of
>>the public API and this is yet another reason why I think so. The
>>tasks API is not well defined as there's, currently, not good way to
>>define the expected input in a backwards compatible way and to provide
>>all the required validation.
>>
>>I like having tasks in Glance, despite my comments above - but I like
>>them for cloud usage and not public usage.
>
>I like them much more if they're not public facing. They're not BAD - 
>they just don't have an end-user semantic.

++

>>As far as Rackspace's docs/endpoint goes, I'd assume this is an error
>>in their documetation since Glance currently doesn't allow[0] for
>>swift URLs to be imported (not even in juno[1]).
>>
>>[0]
>>http://git.openstack.org/cgit/openstack/glance/tree/glance/common/scripts/utils.py#n84
>>
>>[1]
>>http://git.openstack.org/cgit/openstack/glance/tree/glance/common/scripts/utils.py?h=stable/juno#n83
>
>Nope. You MUST upload the image to swift and then provide a swift 
>location. (Infra does this in production, I promise it's the only 
>thing that works)

mmh. That's not vanilla Glance as you can see from the link pointing
to the code in juno (unless it's a previous version w/ different code
that I don't know off). This[0] is the commit where the first version of
the import task was added - it didn't use taskflow back then. I'll
leave someone from Rackspace to chime in here since I don't have any
other context.

Regardless, the above is the exact example of why I believe the task
API should not be considered the end-user, supported, way to upload
images. Requiring users to have an external (or in cloud), public (or
accessible from the cloud) source, were images are going to be
downloaded from, to create an image is far from ideal, usable and,
AFAICR, it was never intended as the recommended upload workflow but
an additional one, which should, arguably, be used only by admins.

[0] https://git.openstack.org/cgit/openstack/glance/commit/?id=186991bb9d2b8c568f3e9a0a89744fd6001ec74a

[snip]

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150914/076aea03/attachment-0001.pgp>