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
