Excerpts from Ian Cordasco's message of 2017-02-13 15:15:12 -0500: > -----Original Message----- > From: Clint Byrum <cl...@fewbar.com> > Reply: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Date: February 13, 2017 at 13:41:00 > To: openstack-dev <openstack-dev@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, annotation, etc. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
