[openstack-dev] [tc][glance][glare][all] glance/glare/artifacts/images at the PTG
clint at fewbar.com
Tue Feb 14 01:11:36 UTC 2017
Excerpts from Ian Cordasco's message of 2017-02-13 15:15:12 -0500:
> -----Original Message-----
> From: Clint Byrum <clint at fewbar.com>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Date: February 13, 2017 at 13:41:00
> To: openstack-dev <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [tc][glance][glare][all]
> glance/glare/artifacts/images at the PTG
> > Excerpts from Mikhail Fedosin's message of 2017-02-13 18:23:19 +0300:
> > > Hello!
> > >
> > >
> > > Let me quickly describe my vision of the problem. I asked this question to
> > > Brian last Friday, because it is evident that the projects have the
> > > intersection in functionality. For this reason, I proposed to bring Glare
> > > back and develop it as a new generation of Glance service. Perhaps such a
> > > solution would be more correct from my point of view.
> > >
> > > Moving away from Glance, let me remind you why we created Glare service.
> > >
> > > Almost every project works with some binary data and must store it
> > > somewhere, and almost always storage itself is not the part of the
> > > project's mission. This issue has often been neglected. For this reason
> > > there is no single recommended method for storing of binary data, which
> > > would have a unified public api and hide all the things of the internal
> > > storage infrastructure.
> > >
> > We have an awesome service for storing binary data in a hierarchical
> > format in Swift. But it's so generic, it can't really just be the image
> > service. But something like Glare is just a way to scope it down and
> > give us a way to ask for "just the images" or "just the heat templates",
> > which I think is a natural thing for cloud users to want.
> > > These questions were answered by Glare. First of all, the service allows to
> > > use different storages for various types of artifacts - an operator can
> > > assign the storage of large files, such as virtual machine images, to
> > > Swift, and for relatively small ones, such as Heat templates, use a mysql
> > > database.
> > >
> > Meh. Swift isn't exactly slow, or cumbersome for small files.
> > > Then, we have to admit that data tends to change, so we added a versioning
> > > of artifacts and dependencies between them, that the user was convenient to
> > > take the data of required version.
> > >
> > Any attempt at versioning that is not git, will frustrate any git user.
> > This cat's already out of the bag, but I'd suggest adding git repositories
> > as a blob container type and finding a way to allow git to push/pull
> > to/from swift. That would be an amazing feature _for swift_ anyway
> > (maybe it already exists?) but it would allow Glare to piggy back on all
> > of the collective versioning capabilities in Git rather than having to
> > chase git.
> So the versioning that's present will frustrate everyone. The
> reasoning for it is that the original Glare developers found a hack
> online to convert the version string into something that a database
> can sort (by turning it into one giant integer basically). (I'm
> certain that's not the only reason, but when challenged with several
> other options they said they couldn't find anyone who had already
> found a way to make it sortable on the version.)
> That aside, I'm not sure anyone wants git (even git-lfs) managing 50GB
> images for them.
Sounds like this was a high level solution that I don't fully understand,
so I'll stop bikeshedding it. But generally I'd say for most OpenStack
services you want to stay low-level whenever possible.
And of course the actual binaries would not be in git. But the metadata
about them would be, which would allow things like bisection,
More information about the OpenStack-dev