On Thu, Dec 5, 2013 at 3:11 PM, Randall Burt <randall.b...@rackspace.com>wrote:
> On Dec 5, 2013, at 4:45 PM, Steve Baker <sba...@redhat.com> > wrote: > > On 12/06/2013 10:46 AM, Mark Washenberger wrote: > > > > > On Thu, Dec 5, 2013 at 1:05 PM, Vishvananda Ishaya > <vishvana...@gmail.com>wrote: > >> >> On Dec 5, 2013, at 12:42 PM, Andrew Plunk <andrew.pl...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
