On Tue, Jan 10, 2017 at 1:03 PM, Flavio Percoco <[email protected]> wrote:
> On 10/01/17 12:35 +0530, Rabi Mishra wrote: > >> On Mon, Jan 9, 2017 at 4:45 PM, Flavio Percoco <[email protected]> wrote: >> >> On 06/01/17 09:34 +0530, Rabi Mishra wrote: >>> >>> On Fri, Jan 6, 2017 at 4:38 AM, Emilien Macchi <[email protected]> >>>> 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: [email protected] >>>>> 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: [email protected] >>>> 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: [email protected] >>> 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: [email protected]?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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Regards, Rabi Misra
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
