Open Stack

Hi Kairat,

I think it's great to try and tease through the various issues here.
I added some comments to the etherpad.

-Stuart

> 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:
>
> https://github.com/openstack/glance-specs/blob/master/specs/newton/approved/glance/glare-api.rst
>
> 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
> Glance.
>
> 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
> cloud.
>
> External locations in Glance have several specialities:
>
>   1.
>
>   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.
>   2.
>
>   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:
>
>   1.
>
>   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.
>   2.
>
>   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.
>   3.
>
>   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:
> https://etherpad.openstack.org/p/glare-locations
>
>
> 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> End of OpenStack-dev Digest, Vol 52, Issue 2
> ********************************************
>