Hi, Please feel free to review the following proposal for 4.5:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111 Here is the summary: Today the way you associate a Compute Offering (CO) or a Disk Offering (DO) with a Primary Storage (PS) is via storage tagging. This has some benefits and drawbacks. One benefit is being able to have some level of vendor independence from the point of view of the CO or DO. For example, if the storage tag of a DO is "Fast", then this can be satisfied by PS that describes itself as "Fast", regardless of vendor. A major drawback with the storage-tagging approach, however, is that you are not easily able to leverage vendor-specific features, which is often why you bought storage from the vendor in question to begin with. Ideally we do not want to add each vendor's features into the system as properties that can be seen by the admin regardless of whether or not the underlying storage he's actually using supports the feature in question. Traditionally, however, this has been business as usual in the CloudStack codebase. Going forward, we want to implement a more fine-grain and generic approach. For example, in the GUI we would like to have a storage provider field for the CO and DO windows (this equates to the name of one and only one storage provider). If the admin inputs a specific storage provider, he can enter in an arbitrary number of key/value pairs in another text field (perhaps we would provide a nice entry dialog to make this easier in the GUI). These key value pairs can be passed into the storage driver when it's asked to create (or update) a volume and the storage driver can decide what each and every key/value pair means, if anything. Thanks! -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud <http://solidfire.com/solution/overview/?video=play>*™*
