[openstack-dev] [Glance][Glare] External locations design
stuart.mclaren at hp.com
stuart.mclaren at hp.com
Tue Aug 2 10:16:16 UTC 2016
I think it's great to try and tease through the various issues here.
I added some comments to the etherpad.
> Hello all,
> I would like to start to describe some design decisions we made in Glare
> code (https://review.openstack.org/#/q/topic:bp/glare-api+status:open). If
> you are not familiar with Glare I suggest you to read the following spec:
> I hope it will help other folks to understand Glare approach and provide
> some constructive feedback for Glare. I think that we can also use Glare
> solution for Glance in near future to address some drawbacks we have in
> Glare locations
> Glance and Glare have possibility to set some external url as
> image(artifact) location. This feature is quite useful for users who would
> like to refer to some external image or artifact (for example, Fedora image
> on official Fedora site) and not to store this image or artifact in the
> External locations in Glance have several specialities:
> It is possible to setup multiple locations for an image. Glance uses
> special location strategy to define which location to use. This strategy
> defined in glance codebase and can be configured in glance conf.
> Glance doesn?t differ image locations specified by url and image
> locations uploaded to Glance backend. Glance has some restrictions about
> which urls to use for locations (see Glance docs for more info).
> Glare external locations designed in different way to address some
> drawbacks we have in Glance. So the approach is the following:
> Glare doesn?t support multiple locations, you can specify dict of blobs
> in artifact type and add url for each blob in dict. User must define a
> name(f.e. region name or priority) for blob in dict and this name can be
> used to retrieve this blob from artifact. So decision about which location
> to use will be outside of Glare.
> Glare adds a special flag to database for external locations. So they
> will be treated differently in Glare when delete artifact. If blob value is
> external url then we don?t need to pass this url to backend and just delete
> the record in DB. For now, Glare allows only http(s) locations set but it
> may be extended in future but the idea still the same: external location
> are just records in DB.
> Glare saves blob size and checksum when specifying external url. When
> user specified url Glare downloads the blob by url, calculates its size and
> checksum. Of course, it leads to some performance degradation but we can
> ensure that the external blob is immutable. We made this because security
> seems more important for Glare than performance. Also there are plans to
> extend this approach to support subscriptions for external locations so we
> can increase secureness of that operation.
> I think that some of the features above can be implemented in Glance. For
> example, we can treat our locations as only read-only links if external
> flag will be implemented. It will allow us to ensure that only blobs
> uploaded through the Glance will be managed.
> Additionally, if we will calculate checksum and size for external urls, we
> can ensure that all multiple locations refers to the same blob. So
> management of multiple locations(deletion/creation) can be more secure.
> Also we can ensure that the external url blob was not changed.
> I understand that we need a spec for that but I would like to discuss this
> at high level first. Here is etherpad for discussion:
> Best regards,
> Kairat Kushaev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160801/5e88c6c1/attachment-0001.html>
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> End of OpenStack-dev Digest, Vol 52, Issue 2
More information about the OpenStack-dev