Open Stack

On Thu, Dec 5, 2013 at 3:11 PM, Randall Burt <randall.burt at rackspace.com>wrote:

>  On Dec 5, 2013, at 4:45 PM, Steve Baker <sbaker at redhat.com>
>  wrote:
>
>  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>wrote:
>
>>
>> On Dec 5, 2013, at 12:42 PM, Andrew Plunk <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>
>> >>> 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.
>
>
>  To add to this, is it that Glance wants to be *more* integrated and
> geared towards vm or container images or that Glance wishes to have more
> intimate knowledge of the things its cataloging *regardless of what those
> things actually might be*? The reason I ask is that Glance supporting only
> "single vm templates" when Heat orchestrates the entire (or almost entire)
> spectrum of core and integrated projects means that its suitability as a
> candidate for a template repository plummets quite a bit.
>
>
Yes, I missed the boat a little bit there. I agree Glance could operate as
a repo for these kinds of templates. I don't know about expanding much
further beyond the Nova / Heat stack. But within that stack, I think the
use cases are largely the same.

It seems like heat templates likely have built-in relationships with vm
templates / images that would be really nice track closely in the Glance
data model--for example if you wanted something like a notification when
deleting an image would invalidate a template you've created. Another
advantage is the sharing model--Glance is still aiming to become something
of an image marketplace, and that kind of sharing is something that I see
being very useful for Heat as well.

Does this response sound more in line? Sorry I'm still catching up on the
thread from before it was tagged with [Glance].


> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131205/fb43f1c5/attachment.html>