cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <jburw...@basho.com>
Subject Re: [PROPOSAL] Collect and provide generic key/value pairs to storage plug-ins
Date Fri, 13 Jun 2014 14:38:24 GMT
Mike,

I completely agree with the need to attach driver-specified key-value pairs to a storage driver
(we have been batting this around for nearly a year).  However, I think this facility should
be generalized to support all drivers (e.g. network, compute, etc) where storage maybe the
first layer to implement it.  For example, we have a raft of places where vendor specific
data/concepts leak into the object model and schema.  For example, in networking, we have
vendor specific API calls. One of the main value propositions of a cloud platform is to provide
a unified abstraction for underlying infrastructure components.  Furthermore, requiring vendor
implements to add API calls further increases the complexity and effort required to support
CloudStack — discouraging their participation.

In terms of the design of itself, I don’t feel that the Map<String, String> getPropertiesAndTypes
is a rich enough semantic for such an extension facility.  First, it does not provide a mechanism
to validate that the form and content of the values being set.  Second, it is incredible lose
contract that does not exploit the Java compiler to ensure drivers are providing well-formed
metadata to the CloudStack orchestration components.  Finally, it does not support notions
such as hinting which fields are required (very useful for creating useful UIs) and constrained
values (rendered as drop downs).  My thoughts are as follows:

Define an ExtenstionPropertyType enumeration with the following types permitted:
STRING
DATE
NUMBER
BOOLEAN
The following methods as well:
Class getType(): The underlying Java type used to represent the type
Object convertFromString(String aValue): Converts a value from a string to the underlying
Java type
String convertToString(Object aValue): Converts a value to a string from the underlying Java
type
Define a ExtensionPropertyDefinition interface that describes the following attributes about
a extension property:
String getName(): The name of the property conforming to JavaBean standards (while we don’t
support reflection, it’s a well known standard by Java developers …)
ExtensionPropertyType getType():  The type of the property
boolean isRequired(): Whether or not a value for the property is required
boolean isCollected(): Whether or not the property’s value is a single value or collected
(default to a list)
Set<String> getConstraints: A list of the values that constrain the values of this extension
property.
List<String> validate(Object aValue): A callback to validate a value for this property
definition — returning a list of strings describing the validation errors.  An empty list
implies a valid value.  An additional nicety for this interface would be to define a type
which the definition would expect of the underlying value to be at runtime. 
Introduce an Extendable interface that indicates that a type can have its data extended with
a set of key-value pairs.  I would define the following methods:
Set<ExtenstionPropertyDefinition> getExtenstionPropertyDefinitions(): The set of extension
property descriptions
Object getExtensionPropertyValue(String aPropertyName): Get a value for an extension property
List<String> validateExtensionProperties(): Validates the values of the extension properties

There are likely pieces I missed and refinements to improve this design — I jotted it down
off the top of my head.  However, we have to ensue that the semantic is rich enough to render
friendly UIs, as well as, protect against GIGO (garbage in, garbage out).  

Finally, I would like to see the design expanded to explain when and where this information
will pass into drivers for use.  As the design stands now, it does not explain how the data
would actually be used during operation.  The scope of these changes is important to understand
for both impact analysis and driver developers and implementors.  Also, I don’t understand
how the addition of generic key-values to drivers would eliminate tags.  As I understand them,
tags are used to establish valid combinations of drivers (e.g. mutual exclusion) to avoid
defining an unimplementable infrastructure configuration.  While I agree with the desire to
eliminate them, I don’t understand how such a facility would contribute to that goal.

Great work putting together an initial design, and getting this important conversation started.

Thanks,
-John

On Jun 10, 2014, at 6:26 PM, Mike Tutkowski <mike.tutkowski@solidfire.com> wrote:

> 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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud™


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