Yep :) This is what we talked about at CCCEU13. On Wednesday, June 11, 2014, Wido den Hollander <w...@widodh.nl> wrote:
> On 06/11/2014 12:26 AM, Mike Tutkowski wrote: > >> Hi, >> >> Please feel free to review the following proposal for 4.5: >> >> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=42566111 >> >> > Is this what we discussed at CCC13 in Amsterdam? Seems like it! > > I'm in favor, since this could add a lot of potentials to the Ceph storage > as well. > > Wido > > 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>*™*
