[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