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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
