Open Stack

On 12/06/2013 01:53 AM, Keith Bray wrote:
> Jay, I don't see reduction.  I count -Glance and +Murano in your email,
> which is net zero addition of projects I think.

Murano is already in the OpenStack world and has been for some time now...

 > Did I miss something?
> Template catalog functionality could go into Heat in the short term with
> no new project additions. It could be built in a way that it would be
> easy to break it out and move it elsewhere in the future, similar to how
> scaling resources is being incubated in Heat, but written in a way that
> it could run standalone or be broken out if needed.

The point is that Murano already has this. I'd say make Murano better by 
making it (only slightly more) flexible, move the block drivers out of 
Glance and into Cinder, and say a farewell to Glance. I just don't see 
the need for a Glance project if there is a flexible catalog service. 
Cinder is for block devices/streaming.

Best,
-jay

> -Keith
>
> On Dec 5, 2013 11:35 PM, Jay Pipes <jaypipes at gmail.com> wrote:
> 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! :)
>
> Best,
> -jay
>
> Best,
> -jay
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>