cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: feature : changing volume properties dynamically in 4.5
Date Tue, 10 Jun 2014 16:18:22 GMT
I plan to draw up a design document surrounding generic key/value pairs
today.

Perhaps you can take a look at it when you have time, Punith?


On Tue, Jun 10, 2014 at 10:06 AM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Hi Punith,
>
> Yeah, I hear you about the number of permutations involved.
>
> Traditionally Compute and Disk Offerings have been immutable. It makes it
> easier from an accounting point of view for chargeback and billing.
>
> You should definitely feel free to extend the CloudStack API. I think
> NetApp did this for one of their storage features in the recent past. This
> way vendor-specific capabilities can be more easily offered without making
> it look like all vendors support those particular features.
>
> I do not yet have any code in master related to generic keys/values. I'm
> still designing this.
>
> How does your schedule look for the 4.5 release? Do you think you might
> have available cycles to help out with this generic key/value
> implementation?
>
> Talk to you later!
> Mike
>
>
> On Tue, Jun 10, 2014 at 7:09 AM, Punith S <punith.s@cloudbyte.com> wrote:
>
>> hi mike,
>>
>> thanks for the reply, i like your approach which is a very generic way
>> and also we only need to do a few changes to the current cloudstack,
>>
>> but on the other hand we are tying every property of the vendor to a disk
>> offering through key/value pairs, since we offer lot of properties like i
>> mentioned, this can create a lot of permutation combinations of disk
>> offerings, for say if i need to turn deduplication On for a specific volume
>> , should i have to create a new disk offering having current properties
>> with deduplication On?
>>
>> is this approach already implemented in the current master ?
>>
>> and also like you mentioned about exposing a new api, is it okay if i
>> expose our own api in my util by extending the PlugableService like in
>> network plugins ?
>>
>> thanks.
>>
>>
>> On Tue, Jun 10, 2014 at 1:17 AM, Mike Tutkowski <
>> mike.tutkowski@solidfire.com> wrote:
>>
>>> Allow me to follow this up with more detail (with regards to what Chris
>>> and I talked about):
>>>
>>> As you are aware, 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.
>>>
>>> This coarse approach, however, was sort of business as usual when I
>>> started in with CloudStack 1.5 years ago.
>>>
>>> That being the case, when I added QoS options to CS, I did so in a way
>>> where the admin would see Min IOPS and Max IOPS options regardless of
>>> whether or not his storage actually supported those controls (to mitigate
>>> this a bit in the GUI, the admin has to explicitly select "Storage QoS"
>>> from a combobox).
>>>
>>> We leverage the same use model with Hypervisor QoS: The admin sees these
>>> options regardless of whether or not they actually apply on the hypervisor
>>> where the VM gets deployed.
>>>
>>> Going forward, we want to implement a more fine-grain and generic
>>> approach.
>>>
>>> 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 and does not use the storage tags
>>> field, 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.
>>>
>>> What do you think about this approach?
>>>
>>> Thanks
>>>
>>>
>>> On Mon, Jun 9, 2014 at 1:14 PM, Mike Tutkowski <
>>> mike.tutkowski@solidfire.com> wrote:
>>>
>>>> Hi Punith,
>>>>
>>>> This kind of a feature is something Chris Suich and I discussed a while
>>>> back.
>>>>
>>>> We talked about leveraging arbitrary key/value pairs to make this
>>>> happen (OpenStack does something similar). The key/value pairs would be
>>>> vendor specific.
>>>>
>>>> If we take a key/value approach, we might be able to make this all work
>>>> the way things work today when the user wants to change an existing Compute
>>>> Offering and/or Disk Offering.
>>>>
>>>> For example, the user would pick a new Compute Offering (with
>>>> presumably has different key/value pairs) and CloudStack could inform the
>>>> applicable storage provider, who could update the volume in question.
>>>>
>>>> This way we don't need to introduce a new API command and the use model
>>>> for the user doesn't really change.
>>>>
>>>> What are you thoughts on this?
>>>>
>>>> Thanks,
>>>> Mike
>>>>
>>>>
>>>> On Mon, Jun 9, 2014 at 8:08 AM, Punith S <punith.s@cloudbyte.com>
>>>> wrote:
>>>>
>>>>> hi guys,
>>>>>
>>>>> since most of the third party storage providers have been implementing
>>>>> 1:1 mapping(managed storage) between a volume(dataset) and a vm
>>>>> disk(vdi/vmdk) for guaranteeing the Qos, i would like to propose a new
>>>>> feature to dynamically change the volume properties supported by storage
>>>>> vendors such as IOPS, Deduplication, Compression, Grace, Syncronization,
>>>>> Latency etc, depending on properties and features supported by respective
>>>>> storage vendors. hence providing more flexibility for users.
>>>>>
>>>>> in case of using default cloudstack storage provider, we can change
>>>>> the properties of the vdi/vmdk files apart from resizing the
>>>>> volume(vdi/vmdk).
>>>>>
>>>>> changes in management server include,
>>>>>
>>>>> new async web api ChangeVolumePropertiesCmd,
>>>>> new method in VolumeApiService for vo and dao validation
>>>>> implementations.
>>>>> new method in VolumeServiceManager for supporting callback and calling
>>>>> the respective storage provider driver's implementation.
>>>>> new method in PrimaryDataStoreDriver interface for implementing
>>>>> respective features according to their storage product.
>>>>>
>>>>> changes in UI include,
>>>>> new changing volume properties widget in volume section, showing
>>>>> different properties depending upon listed storage providers.
>>>>>
>>>>> any suggestions and feedbacks ?
>>>>>
>>>>> thanks
>>>>>
>>>>> --
>>>>> regards,
>>>>>
>>>>> punith s
>>>>> cloudbyte.com
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Mike Tutkowski*
>>>>  *Senior CloudStack Developer, SolidFire Inc.*
>>>> e: mike.tutkowski@solidfire.com
>>>> o: 303.746.7302
>>>> Advancing the way the world uses the cloud
>>>> <http://solidfire.com/solution/overview/?video=play>*™*
>>>>
>>>
>>>
>>>
>>> --
>>> *Mike Tutkowski*
>>> *Senior CloudStack Developer, SolidFire Inc.*
>>> e: mike.tutkowski@solidfire.com
>>> o: 303.746.7302
>>> Advancing the way the world uses the cloud
>>> <http://solidfire.com/solution/overview/?video=play>*™*
>>>
>>
>>
>>
>> --
>> regards,
>>
>> punith s
>> cloudbyte.com
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud
> <http://solidfire.com/solution/overview/?video=play>*™*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*

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