Open Stack

On 16/11/13 23:08 +0800, Zhi Yan Liu wrote:
>>> Enhancing Image Locations:
>>> --------------------------
>>>
>>>
>>> https://etherpad.openstack.org/p/icehouse-summit-enhance-image-location-property
>>>
>>> This session proposed adding several attributes to image locations
>>>
>>> 1. Add 'status' to each location.
>>>
>>> I think consensus was that this approach makes sense moving forward. In
>>> particular, it would be nice to have a 'pending-delete' status for image
>>> locations, so that when you delete a single location from an image it can be
>>> picked up properly by the glance scrubber.
>>>
>>> There was some concern about how we define the overall image status if we
>>> allow other statuses on locations. Is image status just stored independently
>>> of image locations statuses? Or is it newly defined as a function of those
>>> image locations statuses?
>
>I prefer go former way, keep original image's status field
>independent, since IMO we can't obtain 'killed' status base on
>location's status.
>As I proposed, available location status value set is: 'pending',
>'active', 'pending_delete' and 'deleted'.


I instead prefer the later. Having the image status as an independent
field is error prone and could lead to some inconsistencies between
the statuses of the locations and the ones in the image.

I'd rather have a well defined algorithm that calcs the status of the
image based on the status of its locations as opposed to have them
completely independent.

>>>
>>> 3. Add metrics to each image location.
>>>
>>> The essential idea here is to track the performance metrics of each image
>>> location to ensure we choose the fastest location. These metrics would not
>>> be revealed as part of the API.
>>>
>>> I think most of us were initially a bit confused by this suggestion.
>>> However, after talking with Zhi Yan after the session, I think it makes
>>> sense to support this in a local sense rather than storing such information
>>> in the database. Locality is critical because different glance nodes likely
>>> have different relationships to the underlying locations in terms of network
>>> distance, so each node should be gearing towards what is best for it.
>>>
>>> We can also probably reuse a local metrics tracking library to enable
>>> similar optimizations in a future incarnation of the glance client.
>>>
>
>I think the objective is correct, but for realization TBH we have a
>little miscommunication on this part sorry. IMO the metric can be
>added to both Glance server/API side and client side, they are
>independent, we know Glance server side and client side are all need
>to select a location from the list to handle a request - download or
>direct URL consuming. There are two points around this part: metric
>data, and selection function (based on metric). (data structures and
>algorithms, the everlasting topic :-/ )
>
>1. metric data
>
>I consider metric data can be added to database with image location
>(just like metadata field), it will be used by image download handling
>on server/API side, image creator or admin can add node-independent
>indicators or node-dependent indicators to a location via existing
>PATCH API, for former one the indicator can be a global weight for
>customer, for latter one an ABAC[1] based selection function can work
>base on those indicator values. For instance (the indicator key name
>may be need to change):
>
>location entry: [{'url': 'file:///image1', 'metrics': {'weight': 1,
>'node-weights': {'novahost1': 1, 'novahost2': 2}}, 'metadata': {}},
>                          {'url': 'swift://image1', 'metrics':
>{'weight': 2, 'node-weights': {'novahost1': 2, 'novahost2': 1}},
>'metadata': {}}]
>
>In above case 'weight' metrics indicator is a node-independent
>indicators, 'node-weigths' indicator is a node-dependent, and the
>particular selection function (IMO it's a admin configurable option in
>glance-api.conf) should take the responsibility to use the correct, or
>say admin expected, metrics indicator to select a location to handle
>this request. (for API it's 'download')
>
>And glance-api and client both can use this metrics data since the
>metrics can be exposed via standard 'direct url' mechanism, so we
>should allow Glance and client share/reuse selection functions.
>
>Above all metrics are static, they are created by image owner or admin
>via PATCH api. And I agree in next step we need a dynamic local
>metrics storage and relative tracking functions/library on the client
>side, this just is what you said above Mark. They are not conflicting
>but different, again I agree this point as I mentioned in our private
>discussion (sorry if I confuse you :) ).

This clarifies the whole thing. I'd like us to work on a
'user-controlled' weight property first and then we can start thinking
about automating the whole thing, which in this case I'm not fully
convinced about.

>
>I have also mentioned "image handler" point in the session, sorry for
>I highlight it here again since it's really important for Glance Nova
>co-working efficiently, currently the patch is still under review.
>
>1. It give a plug-in point to Nova, to allow a particular image
>handler implementation to consuming image by a special/efficient
>approach via direct location URL. For example zero-copy image rather
>than transferring the actual bits. (Refer my etherpad page if you
>interested)
>2. Above selection function can be add to Nova easily, since we can
>add those selection handling before "image handler" base code, and
>make it be transparent for particular image handling logic.
>3. VMDK/OVA image handler can be implemented base on this also.

I remember us discussing this as part of our 'un-design-session' at
lunch as well. I think this is important and we should start
discussing the implementation.

I think Glance should also have knowledge of Image Grouping - a.k.a
Templates - which eases the download of several images, the
integration with some hypervisors and as you pointed out zero-copy as
well.

Thanks Mark for the summary and Zhi for the follow-up email.
FF


-- 
@flaper87
Flavio Percoco