Just as some background, I'm the Chris from 'NetApp: Chris, David' So, the *_details table is perfect for storing pieces of information that are specific to storage pools or image stores. The kind of information we need to save are global settings and configurations. Things like, enabling enabling reduplication by default when provisioning, provisioning storage as thin/thick, connections & credentials to controllers, etc. That kind of information is not associated with any one zone, pod, cluster, host, storage pool, image store, etc.
By all means, feel free to put information in the *_details table, if that is where it belongs. The point of number 5 is that the ConfigDepot can be used by plugins to store global configuration information. -- Chris Suich chris.su...@netapp.com NetApp Software Engineer Data Center Platforms – Cloud Solutions Citrix, Cisco & Red Hat On Sep 20, 2013, at 1:29 AM, Amit Das <amit....@cloudbyte.com> wrote: > Thanks Edison, the meeting notes were helpful. > > I am implementing a storage plugin for CloudByte & am using *_details table > for storing the plugin related info. > > Can anyone explain what kind/type of plugin data is not suitable in > *_details table (referring to point 5). > > Regards, > Amit > *CloudByte Inc.* <http://www.cloudbyte.com/> > > > On Fri, Sep 20, 2013 at 5:35 AM, Edison Su <edison...@citrix.com> wrote: > >> Meeting notes: >> >> Date: Sep 17, 2013 >> >> Attendees: >> >> NetApp: Chris, David >> >> Citrix: Alex, Animesh, Edison, Srinivas >> >> >> >> 1. TakeSnapshot method on storage plugin. >> >> Chris: TakeSnapshot method is implemented, but backup snapshot is >> failed on the hypervisor side, as the default backup snapshot procedure >> will send a copycommand to Xenserver resource, which can't recognize the >> snapshot created by NetApp storage plugin. >> >> Edison: take snapshot, then backup snapshot to secondary storage >> immediately is the default behavior in CloudStack. There is a way to >> customize it, by extends SnapshotStrategy interface. For example, we can >> write a SnapshotStrategy, which doesn't back up unless anther backup >> snapshot API is called. Or we can add a global configuration parameter to >> disable backup. >> >> Chris: backup snapshot is fine, but we need a way to customize the >> backup logic. Should we need to let hypervisor knows the snapshot created >> by NetApp, Xenserver has an API to introduce a volume/snapshot, but VMware >> seems doesn't have that kind of API. >> >> Edison: There is ways to customize the copy logic, by extending >> copyAsync in storage plugin. Everytime, mgt server sends a copycommand, it >> will go through both source storage provider and destination storage >> provider, If any of them knows how to handle the copycommand, then mgt >> server will handle it to storage provider, otherwise, mgt server will >> handle it to DataMotionService. So there are two ways to customize >> copycommand: >> >> a. implement copyAsync in storage plugin, >> >> b. add a new DataMotionService. >> >> Method a, is easier than method b. >> >> In copyAsync implementation, we can send the copyCommand to SSVM to >> handle the actual snapshot copy, instead of sending to hypervisor host. >> >> Chris: Need the detail about how to implement copyAsync in storage >> plugin: >> >> [Action]: Edison needs to provide detailed information on how to >> implementation of copyAsync >> >> >> >> 2. RevertSnapshot >> >> Chris: RevertSnapshot is never been called in CloudStack. >> >> Edison: CloudStack always assumes the snapshot is created, then will >> be backed up to image store immediately, so no need to revert snapshot. >> >> Chris: need to add revert snapshot functionality on the UI, and API to >> implement revert Snapshot functionality, as the snapshot created on NetApp >> can be reverted back. >> >> [Action]: Edison needs to implement RevertSnapshot, and call storage >> plugin's RevertSnapshot accordingly. >> >> >> >> 3. NetApp volume snapshot. >> >> David: Due to the limitation of NetApp hardware(the number of snapshots >> can be stored on one NetApp volume is limited, less than 255?), we need to >> implement volume snapshot, instead of per VM volume snapshot. >> >> David: Need to change storage plugin API to take snapshots for all the >> VMs created on the primary storage, instead of per one volume, such as >> takeSnapshot(List<VM> vms), then NetApp can take only one snapshot on the >> whole NetApp volume. >> >> Animesh: Does NetApp's hardware has the information for VM's each >> volumes, as there is only one snapshot taking on primary storage? >> >> David: Yes, there is information per volume, we can store them in >> snapshot's path column in CloudStack DB. >> >> Alex: How about queue taking snapshot methods call in storage plugin? >> For example, queue the taking snapshot for several minutes, then issue only >> one take-snapshot command to NetApp hardware. >> >> David: It's doable, but maybe it's better to be done at the CloudStack >> mgt server level. >> >> Alex: Better to send out a proposal on the mailing list, let's see what >> other storage vendor's feedback. If we agree on it's better to implement it >> at mgt server level, then can definitely can implement that. >> >> Alex: Due to tight 4.3 schedule, maybe implement it at the storage >> driver level is more practical. >> >> [Action] NetApp will send out a proposal to mailing list. >> >> >> >> 4. Can't add multiple image storage providers in one CloudStack setup. >> >> Chris: There is on way to let customer to migrate existing NFS >> secondary storage to NetApp's image store, due to the above limitation. >> >> Edison: The reason for only one image storage provider is that: >> whenever CloudStack mgt server needs to access image store, mgt server has >> not hint to pick up an image store, if there are multiple image stores. As >> both image stores are in the same scope. And for operations, like template >> sync between image stores, template copy between zones, will be much >> complicated if there are multiple image stores. >> >> Edison: the proposal is putting the existing image store into >> maintenance mode, then migrate existing templates/snapshots stored on the >> image store to new image store. >> >> [Action] Edison needs to implement image store maintenance mode. NetApp >> may need to provide way to migrate image store. >> >> >> >> 5. How to store configuration for storage plugin: >> >> Animesh: Alex, is it OK to create DB table in storage plugin? >> >> Alex: Better to use *_details table >> >> Chris: For configurations like NetApp server info, or any other >> configuration parameter, it's not suitable in *_details >> >> Alex: Then can store them in configuration table >> >> Chris: configuration table is global, is it OK to store this kind of >> plugin specific information in global configuration? >> >> Alex: In 4.3, people are talking about ConfigurationDepot on the >> mailing list, which is suitable for your case. >> >> [Action]: Chris will take a look at ConfigDepot. >> >> >> >> 6. How to quiescing VMs: >> >> David: What we did in other VMware products is creating a VM snapshot >> first, new linked clone will be created, all the data write will go to the >> new linked clone. NetApp can take snapshot on the parent linked clone, then >> backup it to secondary storage, then revert the snapshot, and delete the >> new linked clone. In this way, we can leverage VM snapshot to quiecse VM, >> then actually backup snapshot through NetApp. >> >> Alex: it's great! We maybe finally have a way to backup VMware snapshot >> efficiently. We need to investigate it, not only for VMware but also for >> Xenserver. >> >> [Action] Both need to investigate the possible way to quiesce VM, then >> come up with new APIs to quiesce/unquiese VM. >> >> >> >> >> >> >> >>
