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 <cl...@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. > > 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev