On 05/20/2016 01:03 PM, Clint Byrum wrote: > Excerpts from Erno Kuvaja's message of 2016-05-20 13:20:11 +0100: >> >> The only reliable way to create Glance images for consumption in general >> manner is to make sure that we use the normal workflows (currently >> uploading the image to Glance and in future the supported manners of Image >> Import) and let Glance and Glance only to deal with it's backends. >> > > Sounds good to me, Glance needs to be the gateway for images, not > anything else. > > I wonder if the shade library would be useful here. > > If Heat were to use shade, which hides the complexities of not only > v1 vs v2, but also v2 with import vs. v2 with upload through glance, > then one could have a fairly generic image type. > > Ansible has done this, which is quite nice, because now ansible users > can be confident that whatever OpenStack cloud they're interacting with, > they can just use the os_image module with the same arguments. > > Anyway, if shade isn't used, Heat will need to do something similar, > which is to provide template users a way to port their templates to the > API's available. Perhaps the provider template system could be used so > each Heat operator can provide a single "image upload" template snippet > that gets used.
Go look at create_image in shade and then all of the different sub-methods that calls and you'll get a ood sense of all of the edge cases > That would bring on a second question, which is how does one even upload > a large file to Heat. This is non-trivial, and I think the only way Heat > can reasonably support this is by handing the user a Swift tempurl in > the create/update stack API whenever a file is referenced. That swift > object would then be used by the engine to proxy that file into glance if > import isn't supported, or if it is, to tell glance where to import from. > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev