You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Rohit Yadav <ro...@shapeblue.com> on 2020/06/23 08:12:56 UTC
[ASK][DISCUSS] Adding support for a new block-storage
based primary storage
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.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [ASK][DISCUSS] Adding support for a new block-storage
based primary storage
Posted by Rohit Yadav <ro...@shapeblue.com>.
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 <Mi...@netapp.com>
Sent: Wednesday, June 24, 2020 01:11
To: Rohit Yadav <ro...@shapeblue.com>; dev@cloudstack.apache.org <de...@cloudstack.apache.org>
Cc: Wido den Hollander <wi...@widodh.nl>; Gabriel Beims Bräscher <ga...@pcextreme.nl>; Will Stevens <ws...@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 <ro...@shapeblue.com>
Date: Tuesday, June 23, 2020 at 2:14 AM
To: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>
Cc: "Tutkowski, Mike" <Mi...@netapp.com>, Wido den Hollander <wi...@widodh.nl>, Gabriel Beims Bräscher <ga...@pcextreme.nl>, Will Stevens <ws...@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.yadav@shapeblue.com
www.shapeblue.com
@shapeblue
rohit.yadav@shapeblue.com
www.shapeblue.com
3 London Bridge Street, 3rd floor, News Building, London SE1 9SGUK
@shapeblue
Re: [ASK][DISCUSS] Adding support for a new block-storage based
primary storage
Posted by "Tutkowski, Mike" <Mi...@netapp.com>.
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 <ro...@shapeblue.com>
Date: Tuesday, June 23, 2020 at 2:14 AM
To: "dev@cloudstack.apache.org" <de...@cloudstack.apache.org>
Cc: "Tutkowski, Mike" <Mi...@netapp.com>, Wido den Hollander <wi...@widodh.nl>, Gabriel Beims Bräscher <ga...@pcextreme.nl>, Will Stevens <ws...@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.yadav@shapeblue.com
www.shapeblue.com
@shapeblue