On Dec 6, 2013, at 10:38 AM, Clint Byrum <cl...@fewbar.com> wrote: > Excerpts from Jay Pipes's message of 2013-12-05 21:32:54 -0800: >> On 12/05/2013 04:25 PM, Clint Byrum wrote: >>> Excerpts from Andrew Plunk's message of 2013-12-05 12:42:49 -0800: >>>>> 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. >>>> >>> >>> I spoke at length via G+ with Randall and Tim about this earlier today. >>> I think I understand the impetus for all of this a little better now. >>> >>> Basically what I'm suggesting is that Glance is only narrow in scope >>> because that was the only object that OpenStack needed a catalog for >>> before now. >>> >>> However, the overlap between a catalog of images and a catalog of >>> templates is quite comprehensive. The individual fields that matter to >>> images are different than the ones that matter to templates, but that >>> is a really minor detail isn't it? >>> >>> I would suggest that Glance be slightly expanded in scope to be an >>> object catalog. Each object type can have its own set of fields that >>> matter to it. >>> >>> This doesn't have to be a minor change to glance to still have many >>> advantages over writing something from scratch and asking people to >>> deploy another service that is 99% the same as Glance. >> >> My suggestion for long-term architecture would be to use Murano for >> catalog/metadata information (for images/templates/whatever) and move >> the block-streaming drivers into Cinder, and get rid of the Glance >> project entirely. Murano would then become the catalog/registry of >> objects in the OpenStack world, Cinder would be the thing that manages >> and streams blocks of data or block devices, and Glance could go away. >> Imagine it... OpenStack actually *reducing* the number of projects >> instead of expanding! :) >> > > Have we not learned our lesson with Nova-Net/Neutron yet? Rewrites of > existing functionality are painful. > > The Murano-concerned people have already stated they are starting over > on that catalog. > > I suggest they start over by expanding Glance's catalog. If the block > streaming bits of Glance need to move somewhere else, that sounds like a > completely separate concern that distracts from this point. > > And to be clear, (I think I will just stop talking as I think I've > made this point), my point is, we have a catalog, let's make it better.
+1 Vish > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
