Open Stack

On 12/5/13 11:33 AM, "Randall Burt" <randall.burt at RACKSPACE.COM> wrote:

>On Dec 5, 2013, at 11:10 AM, Clint Byrum <clint at fewbar.com>
> wrote:
>
>> Excerpts from James Slagle's message of 2013-12-05 08:35:12 -0800:
>>> On Thu, Dec 5, 2013 at 11: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:
>>> 
>>> I'm actually interested in the use cases laid out by Heater from both
>>> a template perspective and image perspective.  For the templates, as
>>> Robert mentioned, Tuskar needs a solution for this requirement, since
>>> it's deploying using templates.  For the images, we have the concept
>>> of a "golden" image in TripleO and are heavily focused on image based
>>> deployments.  Therefore, it seems to make sense that TripleO also
>>> needs a way to version/tag known good images.
>>> 
>>> Given that, I think it makes sense  to do this in a way so that it's
>>> consumable for things other than just templates.  In fact, you can
>>> almost s/template/image/g on the Heater wiki page, and it pretty well
>>> lays out what I'd like to see for images as well.
>>> 
>>>> 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.
>>>> 
>>>> 2: The swift API supports versions. We could also have git as a
>>>> backend.
>>> 
>>> I would definitely like to see a git backend for versioning.  No
>>> reason to reimplement a different solution for what already works
>>> well.  I'm not sure we'd want to put a whole image into git though.
>>> Perhaps just it's manifest (installed components, software versions,
>>> etc) in json format would go into git, and that would be associated
>>> back to the binary image via uuid.  That would even make it easy to
>>> diff changes between versions, etc.
>>> 
>> 
>> Right, git for a big 'ol image makes little sense.
>> 
>> I'm suggesting that one might want to have two glances, one for images
>> which just uses swift versions and would just expose a list of versions,
>> and one for templates which would use git and thus expose more features
>> like a git remote for the repo. I'm not sure if glance has embraced the
>> extension paradigm yet, but this would fall nicely into it.
>
>Alternatively, Glance could have configurable backends for each image
>type allowing for optimization without the (often times messy) extension
>mechanism? This is assuming it doesn't do this already - I really need to
>start digging here. In the spirit of general OpenStack architectural
>paradigms, as long as the service exposes a consistent interface for
>templates that includes versioning support, the back-end store and
>(possibly) the versioning "engine" should certainly be configurable.
>Swift probably makes a decent first/default implementation.

I'm not sure why we are attempting to fit a round peg in a square hole
here. Glance's entire design is built around serving images and there
absolutely is a difference between serving BLOBs versus relatively small
templates. Just look at the existing implementations, Heat already stores
the template directly in the database while Glance stores the blob in an
external file system.

I'm not opposed to having Glance as an optional configurable backend for
Heater but if you look at the existing database models for Glance, an
entirely separate schema would have to be created to support templates. I
also think that having Heater as a layer above Glance or whatever other
backend would allow for the flexibility for Heater's requirements to
diverge in the future from requirements that might make sense for images
but not templates.

-Tim

>
>>>> This feels like something we can add as an optional feature
>>>> without exploding Glance's scope and I imagine it would actually be a
>>>> welcome feature for image authors as well. Think about Ubuntu
>>>>maintaining
>>>> official images. If they can keep the ID the same and just add a
>>>>version
>>>> (allowing users to lock down to a version if updated images cause
>>>>issue)
>>>> that seems like a really cool feature for images _and_ templates.
>>>> 
>>>> 3: I'm sure glance image users would love to have those too.
>>>> 
>>>> 4: Irrelevant. Heat will need to download templates just like nova,
>>>>and
>>>> making images publicly downloadable is also a thing in glance.
>>>> 
>>>> It strikes me that this might be a silo problem instead of an
>>>> actual design problem. Folk should not be worried about jumping into
>>>> Glance and adding features. Unless of course the Glance folk have
>>>> reservations? (adding glance tag to the subject)
>>> 
>>> I'm +1 for adding these types of features to glance, or at least
>>> something common, instead of making it specific to Heat templates.
>>> 
>> 
>> Right, it may be that glance is too limited, but from what I've seen,
>> it is not and it already has the base concepts that "HeaTeR" wants to
>> have available.
>> 
>> _______________________________________________
>> 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