>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. If HeatR and Glance were combined, it would result in taking two very different types of data (template metadata vs image metadata) and mashing them into one service. How would adding the complexity of HeatR benefit Glance, when they are dealing with conceptually two very different types of data? For instance, should a template ever care about the field "minRam" that is stored with an image? Combining them adds a huge development complexity with a very small operations payoff, and so Openstack is already so operationally complex that HeatR as a separate service would be knowledgeable. Only clients of Heat will ever care about data and operations on templates, so I move that HeatR becomes it's own service, or becomes part of Heat. _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
