Adding multi-hypervisor Cloud support

Registered by Zhi Yan Liu

In this case client like Nova can automatically select the correct image format when it consuming an image for particular hypervisor, for example KVM images could potentially be stored on GlusterFS supported for KVM compute nodes whereas ESX images could be stored in a NFS storage. IMO Having multi-hypervisor Clouds is an important use case to us. This enhancement can help improve Cloud deployment flexibility for Cloud owner and operator, and also provide VM more faster for end user.

Overall seems we have two way can go currently:

1. We implement that base on multi-location mechanism, to move 'disk_format', 'container_format' and 'checksum', 'size' property to location from image entry.
2. Add a new function like image-group, i.e., a set of (current style) images, each of which could have different format specifications. End user could create an image-group now by putting a specific tag on all the images in the group.

Blueprint information

Status:
Not started
Approver:
Mark Washenberger
Priority:
Undefined
Drafter:
Zhi Yan Liu
Direction:
Needs approval
Assignee:
Zhi Yan Liu
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

I'm thinking if we can implement image versioning feature also base on this, including thin clone, dependency management, merging and etc.
--zhiyan

Can we rephrase this feature in terms of use cases for the artifacts api?
Essentially, to date we have used locations to specify replicas, mostly. This feature would be something like image "alternatives".
markwash more-info 2014-02-21

I'm a bit worried, as we told, we are putting all hopes on something new for not a good enough reason, and I think it's very hard to port these ideas on to /v2/images so can we make it make more sense with a different abstraction (image-group)? Anyway I/we need to make sure what's going on artifacts part now. @markwash
--zhiyan 2014-02-22

I sympathize with the concern about lumping too many features into some new construct because it seems convenient. Nevertheless I do feel we would be lumping too much into locations if we put this feature there. So the information we really need is, what is the generally acceptable way of accomplishing this feature in terms of the api? Perhaps we can leave that off as a task for the future, when there is time or when artifacts are more clearly structured, and put this feature on the wishlist?
markwash more-info 2014-03-28

now that the artifacts work is moving, i agree with markwash. Let's wishlist for now.
rosmaita wishlist 2014-04-25

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.