[openstack-dev] [tc][glance][glare][all] glance/glare/artifacts/images at the PTG

Mikhail Fedosin mfedosin at gmail.com
Mon Feb 13 17:47:04 UTC 2017

Okay, it seems I did not express myself very well :) But then there is a
rhetorical question: if it's officially recommended to use the service with
the name that starts with "S", why does Nova use a service with the name
beginning with "G" to store its images?

As you may know Glare is a proxy to Swift, Ceph and other possible cloud
storages, and it provides an abstraction (artifact) upon them + several
additional features (like custom data validation and conversion) that Swift
doesn't and shouldn't have. And for sure I was talking about secure and
customizable catalog of binary data with its metadata, and not the concrete
storage implementation. Sorry again for this confusion :)


On Mon, Feb 13, 2017 at 8:04 PM, Ian Cordasco <sigmavirus24 at gmail.com>

> -----Original Message-----
> From: Jeremy Stanley <fungi at yuggoth.org>
> Reply: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Date: February 13, 2017 at 10:14:24
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject:  Re: [openstack-dev] [tc][glance][glare][all]
> glance/glare/artifacts/images at the PTG
> > On 2017-02-13 18:23:19 +0300 (+0300), Mikhail Fedosin wrote:
> > [...]
> > > 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.
> > [...]
> >
> > If you'll forgive the sarcasm, it sounds like you're proposing that
> > OpenStack components should be able to rely on the existence of a
> > standard service suitable for generalized storage and retrieval of
> > arbitrary blobs of data through an API. Our trademark
> > interoperability requirements may even guarantee the presence of one
> > already in any compliant deployment; I'll have to check... ;)
> Well it's a storage service, so I hope the name doesn't start with "S". ;D
> --
> Ian Cordasco
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170213/7b5b3cc4/attachment-0001.html>

More information about the OpenStack-dev mailing list