Open Stack

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.json#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. 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.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

>__________________________________________________________________________
>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


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