On 12/06/2013 10:46 AM, Mark Washenberger wrote: > > > > On Thu, Dec 5, 2013 at 1:05 PM, Vishvananda Ishaya > <[email protected] <mailto:[email protected]>> wrote: > > > On Dec 5, 2013, at 12:42 PM, Andrew Plunk > <[email protected] <mailto:[email protected]>> > 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.
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
