cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <>
Subject [PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins
Date Tue, 10 Jun 2014 22:26:16 GMT

Please feel free to review the following proposal for 4.5:

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

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.


*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
o: 303.746.7302
Advancing the way the world uses the cloud

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message