Open Stack

On Tue, Jan 10, 2017 at 1:03 PM, Flavio Percoco <flavio at redhat.com> wrote:

> On 10/01/17 12:35 +0530, Rabi Mishra wrote:
>
>> On Mon, Jan 9, 2017 at 4:45 PM, Flavio Percoco <flavio at redhat.com> wrote:
>>
>> On 06/01/17 09:34 +0530, Rabi Mishra wrote:
>>>
>>> On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi <emilien at redhat.com>
>>>> wrote:
>>>>
>>>> Greetings Heat folks!
>>>>
>>>>>
>>>>> My question is simple:
>>>>> When do you plan to support Glance v2?
>>>>> https://review.openstack.org/#/c/240450/
>>>>>
>>>>> The spec looks staled while Glance v1 was deprecated in Newton (and v2
>>>>> was started in Kilo!).
>>>>>
>>>>>
>>>>> Hi Emilien,
>>>>>
>>>>
>>>> I think we've not been able to move to v2 due to v1/v2
>>>> incompatibility[1]
>>>> with respect to the location[2] property. Moving to v2 would break all
>>>> existing templates using that property.
>>>>
>>>> I've seen several discussions around that without any conclusion.  I
>>>> think
>>>> we can support a separate v2 image resource and deprecate the current
>>>> one,
>>>> unless there is a better path available.
>>>>
>>>>
>>> Hi Rabi,
>>>
>>> Could you elaborate on why Heat depends on the location attribute? I'm
>>> not
>>> familiar with Heat and knowing this might help me to propose something
>>> (or
>>> at
>>> least understand the difficulties).
>>>
>>> I don't think putting this on hold will be of any help. V1 ain't coming
>>> back and
>>> the improvements for v2 are still under heavy coding. I'd probably
>>> recommend
>>> moving to v2 with a proper deprecation path rather than sticking to v1.
>>>
>>>
>>> Hi Flavio,
>>
>> As much as we would like to move to v2, I think we still don't have a
>> acceptable solution for the question below. There is an earlier ML
>> thread[1], where it was discussed in detail.
>>
>> - What's the migration path for images created with v1 that use the
>> location attribute pointing to an external location?
>>
>
> Moving to Glance v2 shouldn't break this. As in, Glance will still be able
> to
> pull the images from external locations.
>
> Also, to be precise more precise, you actually *can* use locations in V2.
> Glance's node needs to have 2 settings enabled. The first is
> `show_multple_locations` and the second one is a policy config[0]. It's
> however
> not recommended to expose that to end users but that's why it was shielded
> behind policies.
>
> I'd recommend Heat to not use locations as that will require deployers to
> either
> enable them for everyone or have a dedicate glance-api node for Heat.
>
> All that being said, switching to v2 won't prevent Glance from reading
> images
> from external locations if the image records exist already.
>
> [0] https://github.com/openstack/glance/blob/master/etc/policy.j
> son#L16-L18
>
> While answering the above we've to keep in mind the following constraint.
>>
>> - Any change in the image id(new image) would potentially result in nova
>> servers using them in the template being rebuilt/replaced, and we would
>> like to avoid it.
>>
>> There was a suggestion to allow the 'copy-from'  with v2, which would
>> possibly make it easier for us. Is that still an option?
>>
>
> May be, in the long future. The improvements for v2 are still under heavy
> development.
>
> I assume we can probably use glance upload api to upload the image
>> data(after getting it from the external location) for an existing image?
>> Last time i tried to do it, it seems to be not allowed for an 'active'
>> image. It's  possible I'm missing something here.  We don't have a way at
>> present,  for a user to upload an image to heat engine( not sure if we
>> would like do to it either) or heat engine downloading the image from an
>> 'external location' and then uploading it to glance while
>> creating/updating
>> an image resource.
>>
>
> Downloading the image locally and uploading it is a workaround, yes. Not
> ideal
> but it's simple. However, you won't need it for the migration to v2, I
> believe,
> since you can re-use existing images.


AFAIK, we can't do without it, unless 'copy-from' is made available soon,
for two reasons.

-  Image files are always 'external' to heat-engine, unless heatclient is
hacked to
push it to the engine along with the templates/environments, which is not
something
we would do.

- To make the existing templates(with location) usable with glance v2
(newer heat versions)

Heat won't be able to create new images
> and have them point to external locations, though, unless the settings I
> mentioned above have been enabled.
>
> Also, glance location api could probably have been useful here. However, we
>> were advised in the earlier thread not to use it, as exposing the location
>> to the end user is perceived as a security risk.
>>
>
> ++
>
> Flavio
>
>
>
>> [1]  http://lists.openstack.org/pipermail/openstack-dev/2016-May/
>> 094598.html
>>
>>
>> Cheers,
>>
>>> Flavio
>>>
>>>
>>> [1] https://wiki.openstack.org/wiki/Glance-v2-v1-client-compatability
>>>> [2] https://github.com/openstack/heat/blob/master/heat/engine/
>>>> resources/openstack/glance/image.py#L107-L112
>>>>
>>>>
>>>> As an user, I need Glance v2 support so I can remove Glance Registry
>>>>
>>>>> from my deployment. and run pure v2 everywhere in my cloud.
>>>>>
>>>>> Thanks for your help,
>>>>> --
>>>>> Emilien Macchi
>>>>>
>>>>> ____________________________________________________________
>>>>> ______________
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>>> enstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Rabi Misra
>>>>
>>>>
>>> ____________________________________________________________
>>> ______________
>>>
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.op
>>>> enstack.org?subject:unsubscrib
>>>> e
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> --
>>> @flaper87
>>> Flavio Percoco
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>
>> --
>> Regards,
>> Rabi Misra
>>
>
> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __________________________________________________________________________
> 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
>
>


-- 
Regards,
Rabi Misra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170110/db77070b/attachment.html>