Open Stack

On 15 September 2015 at 18:22, Monty Taylor <mordred at inaugust.com> wrote:
> On 09/15/2015 07:09 PM, stuart.mclaren at hp.com wrote:
>>>>
>>>> I've been looking into the existing task-based-upload that Doug
>>>> mentions:
>>>> can anyone clarify the following?
>>>>
>>>> On a default devstack install you can do this 'task' call:
>>>>
>>>> http://paste.openstack.org/show/462919
>>>
>>>
>>> Yup. That's the one.
>>>
>>>> as an alternative to the traditional image upload (the bytes are
>>>> streamed
>>>> from the URL).
>>>>
>>>> It's not clear to me if this is just an interesting example of the kind
>>>> of operator specific thing you can configure tasks to do, or a real
>>>> attempt to define an alternative way to upload images.
>>>>
>>>> The change which added it [1] calls it a 'sample'.
>>>>
>>>> Is it just an example, or is it a second 'official' upload path?
>>>
>>>
>>> It's how you have to upload images on Rackspace.
>>
>>
>> Ok, so Rackspace have a task called image_import. But it seems to take
>> different json input than the devstack version. (A Swift container/object
>> rather than a URL.)
>>
>> That seems to suggest that tasks really are operator specific, that there
>> is no standard task based upload ... and it should be ok to try
>> again with a clean slate.
>
>
> Yes - as long as we don't use the payload as a defacto undefined API to
> avoid having specific things implemented in the API I think we're fine.
>
> Like, if it was:
>
> glance import-image
>
> and that presented an interface that had a status field ... I mean, that's a
> known OpenStack pattern - it's how nova boot works.
>
> Amongst the badness with this is:
>
> a) It's only implemented in one cloud and at that cloud with special code
> b) The interface is "send some JSON to this endpoint, and we'll infer a
> special sub-API from the JSON, which is not a published nor versioned API"

+1 for moving forward with a "works everywhere" upload API.

My memory of the issue here, is the want to validate images, before
allowing users to create instances from that image. If we can get that
working with the regular HTTP upload method, I think we will have
sorted the main issue.

Its more about failing as early as possible and defence in depth,
rather than a specific threat thats not already protected against,
AFAIK.

Forcing copy from swift is handy in terms of reducing glance API load,
but that shouldn't be done at the cost of interoperability.

Thanks,
johnthetubaguy

>>> If you want to see the
>>> full fun:
>>>
>>>
>>> https://github.com/openstack-infra/shade/blob/master/shade/__init__.py#L1335-L1510
>>>
>>>
>>> Which is "I want to upload an image to an OpenStack Cloud"
>>>
>>> I've listed it on this slide in CLI format too:
>>>
>>> http://inaugust.com/talks/product-management/index.html#/27
>>>
>>> It should be noted that once you create the task, you need to poll the
>>> task with task-show, and then the image id will be in the completed
>>> task-show output.
>>>
>>> Monty
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev