<html><body>
<p><font size="2" face="sans-serif">I thought about that, i.e. first step in implementation just adding templates, but like you said, you might end up duplicating 5 of the 7 tables in the Glance database, for every new "asset type" (image, template, etc). Then you would do a similar thing for the endpoints. So, I'm not sure what's a better way to approach this. For all I know, doing a "s/image/asset/g" for *.py,, adding attribute images.type, and a little more refactoring, might get us 80% of the asset management functionality that we would need initially ;-) Not knowing the Glance code base I'm only going by the surface footprint, so I'll leave it to the experts to comment on what would be a good approach to take Glance to the next level.</font><br>
<font size="2" face="sans-serif"><br>
</font><br>
<font size="2" face="sans-serif">Edmund Troche</font><br>
<br>
<img width="16" height="16" src="cid:1__=09BBF6AADFED5DF98f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Randall Burt ---12/06/2013 04:47:38 PM---I too have warmed to this idea but wonder about the actual i"><font size="2" color="#424282" face="sans-serif">Randall Burt ---12/06/2013 04:47:38 PM---I too have warmed to this idea but wonder about the actual implementation around it. While I like wh</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Randall Burt <randall.burt@RACKSPACE.COM></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">12/06/2013 04:47 PM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [heat] [glance] Heater Proposal</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<font size="3" face="serif">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. </font><br>
<br>
<font size="3" face="serif">On Dec 6, 2013, at 4:23 PM, Edmund Troche <</font><a href="mailto:edmund.troche@us.ibm.com"><font size="3" color="#0000FF" face="serif"><u>edmund.troche@us.ibm.com</u></font></a><font size="3" face="serif">></font><br>
<font size="3" face="serif"> wrote:</font><br>
<ul style="padding-left: 36pt"><br>
<font size="2" face="sans-serif">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"). </font><font size="3" face="serif"><br>
</font><font size="2" face="sans-serif"><br>
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: </font><a href="http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification/"><font size="2" color="#0000FF" face="sans-serif"><u>http://open-services.net/wiki/asset-management/OSLC-Asset-Management-2.0-Specification/</u></font></a><font size="2" face="sans-serif">. Looking at this spec, it probably has more than we need, but there's plenty we could borrow from it.</font><font size="3" face="serif"><br>
<br>
</font><font size="2" face="sans-serif"><br>
Edmund Troche</font><font size="3" face="serif"><br>
<br>
<br>
<graycol.gif></font><font size="2" color="#424282" face="sans-serif">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</font><font size="3" face="serif"><br>
</font><font size="1" color="#5F5F5F" face="sans-serif"><br>
From: </font><font size="1" face="sans-serif">Georgy Okrokvertskhov <</font><a href="mailto:gokrokvertskhov@mirantis.com"><font size="1" color="#0000FF" face="sans-serif"><u>gokrokvertskhov@mirantis.com</u></font></a><font size="1" face="sans-serif">></font><font size="1" color="#5F5F5F" face="sans-serif"><br>
To: </font><font size="1" face="sans-serif">"OpenStack Development Mailing List (not for usage questions)" <</font><a href="mailto:openstack-dev@lists.openstack.org"><font size="1" color="#0000FF" face="sans-serif"><u>openstack-dev@lists.openstack.org</u></font></a><font size="1" face="sans-serif">>, </font><font size="1" color="#5F5F5F" face="sans-serif"><br>
Date: </font><font size="1" face="sans-serif">12/06/2013 01:34 PM</font><font size="1" color="#5F5F5F" face="sans-serif"><br>
Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [heat] [glance] Heater Proposal</font>
<p><hr width="100%" size="2" align="left" noshade><font size="3" face="serif"><br>
<br>
<br>
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.<br>
<br>
Thanks<br>
Georgy<br>
<br>
<br>
On Fri, Dec 6, 2013 at 11:11 AM, Vishvananda Ishaya <</font><a href="mailto:vishvananda@gmail.com" target="_blank"><font size="3" color="#0000FF" face="serif"><u>vishvananda@gmail.com</u></font></a><font size="3" face="serif">> wrote: </font>
<ul style="padding-left: 36pt"><font size="3" face="serif"><br>
On Dec 6, 2013, at 10:38 AM, Clint Byrum <</font><a href="mailto:clint@fewbar.com"><font size="3" color="#0000FF" face="serif"><u>clint@fewbar.com</u></font></a><font size="3" face="serif">> wrote:<br>
<br>
> Excerpts from Jay Pipes's message of 2013-12-05 21:32:54 -0800:<br>
>> On 12/05/2013 04:25 PM, Clint Byrum wrote:<br>
>>> Excerpts from Andrew Plunk's message of 2013-12-05 12:42:49 -0800:<br>
>>>>> Excerpts from Randall Burt's message of 2013-12-05 09:05:44 -0800:<br>
>>>>>> On Dec 5, 2013, at 10:10 AM, Clint Byrum <clint at </font><a href="http://fewbar.com/" target="_blank"><font size="3" color="#0000FF" face="serif"><u>fewbar.com</u></font></a><font size="3" face="serif">><br>
>>>>>> wrote:<br>
>>>>>><br>
>>>>>>> Excerpts from Monty Taylor's message of 2013-12-04 17:54:45 -0800:<br>
>>>>>>>> Why not just use glance?<br>
>>>>>>>><br>
>>>>>>><br>
>>>>>>> I've asked that question a few times, and I think I can collate the<br>
>>>>>>> responses I've received below. I think enhancing glance to do these<br>
>>>>>>> things is on the table:<br>
>>>>>>><br>
>>>>>>> 1. Glance is for big blobs of data not tiny templates.<br>
>>>>>>> 2. Versioning of a single resource is desired.<br>
>>>>>>> 3. Tagging/classifying/listing/sorting<br>
>>>>>>> 4. Glance is designed to expose the uploaded blobs to nova, not users<br>
>>>>>>><br>
>>>>>>> My responses:<br>
>>>>>>><br>
>>>>>>> 1: Irrelevant. Smaller things will fit in it just fine.<br>
>>>>>><br>
>>>>>> 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.<br>
>>>>>><br>
>>>>><br>
>>>>> Optimizations can be improved for various use cases. The design, however,<br>
>>>>> has no assumptions that I know about that would invalidate storing blobs<br>
>>>>> of yaml/json vs. blobs of kernel/qcow2/raw image.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> 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.<br>
>>>> 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.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>><br>
>>> I spoke at length via G+ with Randall and Tim about this earlier today.<br>
>>> I think I understand the impetus for all of this a little better now.<br>
>>><br>
>>> Basically what I'm suggesting is that Glance is only narrow in scope<br>
>>> because that was the only object that OpenStack needed a catalog for<br>
>>> before now.<br>
>>><br>
>>> However, the overlap between a catalog of images and a catalog of<br>
>>> templates is quite comprehensive. The individual fields that matter to<br>
>>> images are different than the ones that matter to templates, but that<br>
>>> is a really minor detail isn't it?<br>
>>><br>
>>> I would suggest that Glance be slightly expanded in scope to be an<br>
>>> object catalog. Each object type can have its own set of fields that<br>
>>> matter to it.<br>
>>><br>
>>> This doesn't have to be a minor change to glance to still have many<br>
>>> advantages over writing something from scratch and asking people to<br>
>>> deploy another service that is 99% the same as Glance.<br>
>><br>
>> My suggestion for long-term architecture would be to use Murano for<br>
>> catalog/metadata information (for images/templates/whatever) and move<br>
>> the block-streaming drivers into Cinder, and get rid of the Glance<br>
>> project entirely. Murano would then become the catalog/registry of<br>
>> objects in the OpenStack world, Cinder would be the thing that manages<br>
>> and streams blocks of data or block devices, and Glance could go away.<br>
>> Imagine it... OpenStack actually *reducing* the number of projects<br>
>> instead of expanding! :)<br>
>><br>
><br>
> Have we not learned our lesson with Nova-Net/Neutron yet? Rewrites of<br>
> existing functionality are painful.<br>
><br>
> The Murano-concerned people have already stated they are starting over<br>
> on that catalog.<br>
><br>
> I suggest they start over by expanding Glance's catalog. If the block<br>
> streaming bits of Glance need to move somewhere else, that sounds like a<br>
> completely separate concern that distracts from this point.<br>
><br>
> And to be clear, (I think I will just stop talking as I think I've<br>
> made this point), my point is, we have a catalog, let's make it better.<br>
<br>
+1<br>
<br>
Vish<br>
<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> </font><a href="mailto:OpenStack-dev@lists.openstack.org"><font size="3" color="#0000FF" face="serif"><u>OpenStack-dev@lists.openstack.org</u></font></a><font size="3" face="serif"><br>
> </font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="#0000FF" face="serif"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a><font size="3" face="serif"><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list</font><font size="3" color="#0000FF" face="serif"><u><br>
</u></font><a href="mailto:OpenStack-dev@lists.openstack.org"><font size="3" color="#0000FF" face="serif"><u>OpenStack-dev@lists.openstack.org</u></font></a><font size="3" color="#0000FF" face="serif"><u><br>
</u></font><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><font size="3" color="#0000FF" face="serif"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></a></ul>
<font size="3" face="serif"><br>
<br>
<br>
-- <br>
Georgy Okrokvertskhov<br>
Technical Program Manager,<br>
Cloud and Infrastructure Services,<br>
Mirantis</font><font size="3" color="#0000FF" face="serif"><u><br>
</u></font><a href="http://www.mirantis.com/" target="_blank"><font size="3" color="#0000FF" face="serif"><u>http://www.mirantis.com</u></font></a><font size="3" face="serif"><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284</font><tt><font size="2">_______________________________________________<br>
OpenStack-dev mailing list</font></tt><tt><font size="2" color="#0000FF"><u><br>
</u></font></tt><a href="mailto:OpenStack-dev@lists.openstack.org"><tt><font size="2" color="#0000FF"><u>OpenStack-dev@lists.openstack.org</u></font></tt></a><tt><font size="2" color="#0000FF"><u><br>
</u></font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size="2" color="#0000FF"><u>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</u></font></tt></a><font size="3" face="serif"><br>
</font><br>
<font size="3" face="serif">_______________________________________________<br>
OpenStack-dev mailing list</font><font size="3" color="#0000FF" face="serif"><u><br>
</u></font><a href="mailto:OpenStack-dev@lists.openstack.org"><font size="3" color="#0000FF" face="serif"><u>OpenStack-dev@lists.openstack.org</u></font></a><font size="3" face="serif"><br>
</font><font size="3" face="serif"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></ul>
<tt><font size="2">_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
</font></tt><br>
</body></html>