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 [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev End of OpenStack-dev Digest, Vol 52, Issue 2 ********************************************
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
