On Fri, Dec 6, 2013 at 2:43 PM, Randall Burt <randall.b...@rackspace.com>wrote:
> I too have warmed to this idea but wonder about the actual implementation > around it. While I like where Edmund is going with this, I wonder if it > wouldn't be valuable in the short-to-mid-term (I/J) to just add /templates > to Glance (/assemblies, /applications, etc) along side /images. Initially, > we could have separate endpoints and data structures for these different > asset types, refactoring the easy bits along the way and leveraging the > existing data storage and caching bits, but leaving more disruptive changes > alone. That can get the functionality going, prove some concepts, and allow > all of the interested parties to better plan a more general v3 api. > I think this trajectory makes a lot of sense as an initial plan. We should definitely see how much overlap there is through a detailed proposal. If there are some extremely low-hanging fruit on the side of generalization, maybe we can revise such a proposal before we get going too far. It also occurs to me that this is a very big shift in focus for the Glance team, however, so perhaps it would make sense to try to discuss this at the midcycle meetup [1]? I know some of the discussion there is going to revolve around finding a better solution to the image sharing / image marketplace problem. [1] http://lists.openstack.org/pipermail/openstack-dev/2013-November/019230.html > > On Dec 6, 2013, at 4:23 PM, Edmund Troche <edmund.tro...@us.ibm.com> > wrote: > > I agree with what seems to also be the general consensus, that Glance > can "become" Heater+Glance (the service that manages images in OS today). > Clearly, if someone looks at the Glance DB schema, APIs and service type > (as returned by keystone service-list), all of the terminology is about > images, so we would need to more formally define what are the > characteristics or "image", "template", maybe "assembly", "components" etc > and find what is a good generalization. When looking at the attributes for > "image" (image table), I can see where there are a few that would be > generic enough to apply to "image", "template" etc, so those could be taken > to be the base set of attributes, and then based on the "type" (image, > template, etc) we could then have attributes that are type-specific (maybe > by leveraging what is today "image_properties"). > > As I read through the discussion, the one thing that came to mind is > "asset management". I can see where if someone bothers to create an image, > or a template, then it is for a good reason, and that perhaps you'd like to > maintain it as an IT asset. Along those lines, it occurred to me that maybe > what we need is to make Glance some sort of asset management service that > can be leveraged by Service Catalogs, Nova, etc. Instead of storing > "images" and "templates" we store assets of one kind or another, with > artifacts (like files, image content, etc), and associated metadata. There > is some work we could borrow from, conceptually at least, from OSLC's Asset > Management specification: > http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification/. > Looking at this spec, it probably has more than we need, but there's plenty > we could borrow from it. > > > Edmund Troche > > > <graycol.gif>Georgy Okrokvertskhov ---12/06/2013 01:34:13 PM---As a > Murano team we will be happy to contribute to Glance. Our Murano metadata > repository is a stand > > > From: Georgy Okrokvertskhov <gokrokvertsk...@mirantis.com> > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@lists.openstack.org>, > Date: 12/06/2013 01:34 PM > Subject: Re: [openstack-dev] [heat] [glance] Heater Proposal > > ------------------------------ > > > > As a Murano team we will be happy to contribute to Glance. Our Murano > metadata repository is a standalone component (with its own git > repository)which is not tightly coupled with Murano itself. We can easily > add our functionality to Glance as a new component\subproject. > > Thanks > Georgy > > > On Fri, Dec 6, 2013 at 11:11 AM, Vishvananda Ishaya < > *vishvana...@gmail.com* <vishvana...@gmail.com>> wrote: > > > On Dec 6, 2013, at 10:38 AM, Clint Byrum > <*cl...@fewbar.com*<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*<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. > >>>> > >>>> 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*<OpenStack-dev@lists.openstack.org> > > > *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > _______________________________________________ > OpenStack-dev mailing list > *OpenStack-dev@lists.openstack.org* <OpenStack-dev@lists.openstack.org> > *http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev*<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > > > > > -- > Georgy Okrokvertskhov > Technical Program Manager, > Cloud and Infrastructure Services, > Mirantis > *http://www.mirantis.com* <http://www.mirantis.com/> > Tel. +1 650 963 9828 > Mob. +1 650 996 3284_______________________________________________ > 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
