Hi Mike,

Thanks for replying, you've answered all my concerns as well as the historic 
background and references. Since the feature is KVM specific I think even if 
separate volume storage driven/plugin is implemented, it will still require 
adding support/hooks in various Command handlers in many classes/methods. I'll 
take your guidance and explore the most suitable approach.

Thanks again and regards.

________________________________
From: Tutkowski, Mike <mike.tutkow...@netapp.com>
Sent: Wednesday, June 24, 2020 01:11
To: Rohit Yadav <rohit.ya...@shapeblue.com>; dev@cloudstack.apache.org 
<dev@cloudstack.apache.org>
Cc: Wido den Hollander <w...@widodh.nl>; Gabriel Beims Bräscher 
<gabr...@pcextreme.nl>; Will Stevens <wstev...@cloudops.com>
Subject: Re: [ASK][DISCUSS] Adding support for a new block-storage based 
primary storage


Hi Rohit,



I’m guessing in your case (since you say this storage is similar to RBD) that 
it would, as you say, be simpler to make changes to 
CloudStackPrimaryDataStoreLifeCycleImpl to support this new storage type.



Of course, this then adds yet one more storage type that that particular class 
is responsible for, thus complicating its code.



If making those changes in CloudStackPrimaryDataStoreLifeCycleImpl doesn’t 
complicate that code too much more, then it’s probably OK. However, I really 
like the approach of being able to write a new plug-in per storage type (as you 
say, as is done with SolidFire, Datera, and CloudByte). In this case, you don’t 
have to worry so much about breaking storage types that already are working 
and/or complicating the logic of CloudStackPrimaryDataStoreLifeCycleImpl to 
support another storage type.



I think the reason CloudStackPrimaryDataStoreLifeCycleImpl supports multiple 
storage types in the first place probably dates back to when CloudStack’s 
storage component was first modularized in such a way that it could support 
storage plug-ins (back in 2012 and 2013 for CloudStack 4.1). At this time, I 
believe Edison Su took the originally supported storage types and put them in 
CloudStackPrimaryDataStoreLifeCycleImpl (others have probably added new storage 
types in here, as well, over the years). Then I came along and started writing 
a completely separate storage plug-in for SolidFire for CloudStack 4.2 (which 
Edison’s new storage architecture for 4.1 began to enable). CloudByte and 
Datera liked the separate storage plug-in approach, so they went the same route 
in this regard as I did with SolidFire.



So, anyways, those are some of my thoughts on the matter.



Talk to you later!

Mike



From: Rohit Yadav <rohit.ya...@shapeblue.com>
Date: Tuesday, June 23, 2020 at 2:14 AM
To: "dev@cloudstack.apache.org" <dev@cloudstack.apache.org>
Cc: "Tutkowski, Mike" <mike.tutkow...@netapp.com>, Wido den Hollander 
<w...@widodh.nl>, Gabriel Beims Bräscher <gabr...@pcextreme.nl>, Will Stevens 
<wstev...@cloudops.com>
Subject: [ASK][DISCUSS] Adding support for a new block-storage based primary 
storage



NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



All, /cc Mike, Wido, Gabriel, Will



Support for some primary storage pool types (such as RBD, Gluster, CLVM, VMFS) 
is added in the default datastore provider 
(CloudStackPrimaryDataStoreLifeCycleImpl) while for others (such as Solidfire, 
Datera, CloudByte etc) is implemented in its own lifecycle/driver.



I'm trying to write a design doc for adding support for a block-storage based 
volume storage similar to RBD (primarily for KVM) and I looked into the storage 
sub-system [1] design doc as well as how RBD[2] support was added and I'm 
evaluating pros and cons of adding the support by (a) extending the default 
volume provider versus (b) writing a new volume storage driver/plugin, and both 
would require adding handlers in libvirt/kvm server resource. Approach #a would 
be simpler to implement than #b based on code investigation, what are your 
thoughts and advice on this? Thanks.



[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+subsystem+2.0

[2] 
https://github.com/apache/cloudstack/commit/406fd95d87bfcdbb282d65589ab1fb6e9fd0018a



Regards.

rohit.ya...@shapeblue.com
www.shapeblue.com
@shapeblue




rohit.ya...@shapeblue.com 
www.shapeblue.com
3 London Bridge Street,  3rd floor, News Building, London  SE1 9SGUK
@shapeblue
  
 

Reply via email to