[openstack-dev] [heat] [glance] Heater Proposal

Steve Baker sbaker at redhat.com
Thu Dec 5 22:45:54 UTC 2013

On 12/06/2013 10:46 AM, Mark Washenberger wrote:
> On Thu, Dec 5, 2013 at 1:05 PM, Vishvananda Ishaya
> <vishvananda at gmail.com <mailto:vishvananda at gmail.com>> wrote:
>     On Dec 5, 2013, at 12:42 PM, Andrew Plunk
>     <andrew.plunk at RACKSPACE.COM <mailto:andrew.plunk at RACKSPACE.COM>>
>     wrote:
>     >> Excerpts from Randall Burt's message of 2013-12-05 09:05:44 -0800:
>     >>> On Dec 5, 2013, at 10:10 AM, Clint Byrum <clint at fewbar.com
>     <http://fewbar.com>>
>     >>> wrote:
>     >>>
>     >>>> Excerpts from Monty Taylor's message of 2013-12-04 17:54:45
>     -0800:
>     >>>>> Why not just use glance?
>     >>>>>
>     >>>>
>     >>>> I've asked that question a few times, and I think I can
>     collate the
>     >>>> responses I've received below. I think enhancing glance to do
>     these
>     >>>> things is on the table:
>     >>>>
>     >>>> 1. Glance is for big blobs of data not tiny templates.
>     >>>> 2. Versioning of a single resource is desired.
>     >>>> 3. Tagging/classifying/listing/sorting
>     >>>> 4. Glance is designed to expose the uploaded blobs to nova,
>     not users
>     >>>>
>     >>>> My responses:
>     >>>>
>     >>>> 1: Irrelevant. Smaller things will fit in it just fine.
>     >>>
>     >>> Fitting is one thing, optimizations around particular
>     assumptions about the size of data and the frequency of
>     reads/writes might be an issue, but I admit to ignorance about
>     those details in Glance.
>     >>>
>     >>
>     >> Optimizations can be improved for various use cases. The
>     design, however,
>     >> has no assumptions that I know about that would invalidate
>     storing blobs
>     >> of yaml/json vs. blobs of kernel/qcow2/raw image.
>     >
>     > I think we are getting out into the weeds a little bit here. It
>     is important to think about these apis in terms of what they
>     actually do, before the decision of combining them or not can be made.
>     >
>     > I think of HeatR as a template storage service, it provides
>     extra data and operations on templates. HeatR should not care
>     about how those templates are stored.
>     > Glance is an image storage service, it provides extra data and
>     operations on images (not blobs), and it happens to use swift as a
>     backend.
>     This is not completely correct. Glance already supports something
>     akin to templates. You can create an "image" with metadata
>     properties that specifies a complex block device mapping which
>     would allow for multiple volumes and images to connected to the vm
>     at boot time. This is functionally a template for a single vm.
>     Glance is pretty useless if is just an "image storage" service, we
>     already have other places that can store bits (swift, cinder). It
>     is much more valuable as a searchable repository of bootable
>     templates. I don't see any reason why this idea couldn't be
>     extended to include more complex templates that could include more
>     than one vm.
> FWIW I agree with all of this. I think Glance's real role in OpenStack
> is as a helper and optionally as a gatekeeper for the category of
> "stuff Nova can boot". So any parameter that affects what Nova is
> going to boot should in my view be something Glance can be aware of.
> This list of parameters *could* grow to include multiple device
> images, attached volumes, and other things that currently live in the
> realm of flavors such as extra hardware requirements and networking
> aspects.
> Just so things don't go too crazy, I'll add that since Nova is
> generally focused on provisioning individual VMs, anything above the
> level of an individual VM should be out of scope for Glance.
> I think Glance should alter its approach to be less generally agnostic
> about the contents of the objects it hosts. Right now, we are just
> starting to do this with images, as we slowly advance on offering
> server side format conversion. We could find similar use cases for
> single vm templates.

The average heat template would provision more than one VM, plus any
number of other cloud resources.

An image is required to provision a single nova server;
a template is required to provision a single heat stack.

Hopefully the above "single vm" policy could be reworded to be agnostic
to the service which consumes the object that glance is storing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131206/fe572a8f/attachment.html>

More information about the OpenStack-dev mailing list