Thanks for that bug link, Jessica. I went ahead and added a comment with content drawn from this e-mail thread.
I believe we'll have to wait for Edison to get back to us to see when the feature will be documented (at the moment, Vladimir and I are both interested in creating plug-ins, but will not more info to do so). Also, we have (as you can see in this thread) a pending question related to what the framework should do versus what the storage plug-ins should do. Thanks again! On Tue, Mar 26, 2013 at 12:58 PM, Jessica Tomechak < jessica.tomec...@gmail.com> wrote: > There is a bug filed to track documentation for this feature. It's > currently unassigned. Looks like a lot of good information is going past in > this email thread. Please consider this a friendly invitation to pull any > useful conclusions and use cases out of here and put them in the doc bug > comments, or update the FS, or create a wiki page and link to it from the > doc bug, so that the info is easy to find for whoever ends up fixing the > bug. > > https://issues.apache.org/jira/browse/CLOUDSTACK-885 > > Thanks, > Jessica T. > > On Mon, Mar 25, 2013 at 10:10 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > > > Exactly, John ... All of what you said, plus - for example - it really > puts > > the onus on the plug-in developer to update the plug in whenever we add > > support for a new hypervisor (say, HyperV). > > > > I'm happy to help out with this effort to extract hypervisor knowledge > away > > from these plug-ins, so - if we go this route - please feel free to bring > > me in. > > > > Let's see what Edison thinks. > > > > > > On Mon, Mar 25, 2013 at 11:02 PM, John Burwell <jburw...@basho.com> > wrote: > > > > > Mike, > > > > > > +1 .. If storage plugins have to understand each hypervisor, the > > > support matrix becomes unmaintainably complex. We have a variety of > > > abstractions commonly understood by hypervisors (e.g. LUNs, I/O > > > streams, sockets, files, etc) that a storage can either be yielded or > > > manipulated by a storage plugin that it is possible to decouple > > > hypervisors and storage entities. > > > > > > Thanks, > > > -John > > > > > > > > > > > > > > > On Mar 25, 2013, at 5:37 PM, Mike Tutkowski > > > <mike.tutkow...@solidfire.com> wrote: > > > > > > > Hey Edison, > > > > > > > > So...if you think my understanding is correct (please check out the > > > e-mail > > > > below), then I have a question. > > > > > > > > Do we really want to have the storage plug-ins taking on the > > > responsibility > > > > of talking to the hypervisors to hook up the storage that they just > > > created= > > > > ? > > > > > > > > I'm a bit familiar with how OpenStack does this and it seems that it > > only > > > > has its storage plug-ins create a volume (LUN, whatever) and then the > > > > framework handles the process of dealing with the hypervisor in > > question > > > to > > > > hook up the storage. > > > > > > > > It seems like otherwise we'd need to create a utility for all storage > > > > plug-ins to share otherwise they'd be duplicating efforts in talking > to > > > > hypervisors. > > > > > > > > What do you think? > > > > > > > > > > > > On Thu, Mar 21, 2013 at 7:52 PM, Mike Tutkowski < > > > > mike.tutkow...@solidfire.com> wrote: > > > > > > > >> Hi Edison, > > > >> > > > >> I believe I understand the requirements for the plug-in better now. > > > >> > > > >> It sounds like the flow will be as such: > > > >> > > > >> * The user executes a Compute or Disk Offering that is tied via a > > > storage > > > >> tag to a Primary Storage that is associated with a plug-in. > > > >> > > > >> * The storage framework will ask the plug-in to create a volume. > The > > > >> plug-in will create a volume and hook the volume up to the > appropriate > > > >> hypervisor. For VMware, this means the plug-in will create a > > Datastore. > > > >> For XenServer, this means the plug-in will create a Storage > > Repository. > > > >> (So on and so forth for other hypervisors.) > > > >> > > > >> * The VM or data disk is then deployed to the hypervisor. > > > >> > > > >> Does that sound correct, Edison? > > > >> > > > >> Thanks! > > > >> > > > >> > > > >> On Thu, Mar 21, 2013 at 5:44 PM, Edison Su <edison...@citrix.com> > > > wrote: > > > >> > > > >>> ** ** > > > >>> > > > >>> ** ** > > > >>> > > > >>> *From:* Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] > > > >>> *Sent:* Thursday, March 21, 2013 4:18 PM > > > >>> *To:* Edison Su > > > >>> *Subject:* Re: Storage Subsystem 2.0 plugin docs**** > > > >>> > > > >>> ** ** > > > >>> > > > >>> Hi Edison,**** > > > >>> > > > >>> ** ** > > > >>> > > > >>> I wanted to dive into these comments a bit more:**** > > > >>> > > > >>> ** ** > > > >>> > > > >>> [Edison] plugin=92s driver->createasync will be called when mgt > > server > > > w= > > > > ant > > > >>> to create a volume on the storage. In the driver=92s > implementation, > > > it = > > > > can > > > >>> directly call storage box=92s api, or send a command to hypervisor > > > host,= > > > > then > > > >>> call storage box=92s api to create an iscsi.**** > > > >>> > > > >>> Then create a datastore(for vmware), SR(for xenserver), or storage > > > >>> pool(for KVM) on hypervisor host, based on the iscsi iqn.**** > > > >>> > > > >>> If the volume is created from a template(for root disk), need to > > find a > > > >>> way to import that template(which is nfs based currently, it will > be > > > jus= > > > > t a > > > >>> plain http url the future) into the root disk.**** > > > >>> > > > >>> The part about creating a datastore or a storage repository...is > that > > > >>> something the plug-in will be responsible for doing or will the > > storage > > > >>> framework cover that piece? I'm thinking the storage framework > will > > > sin= > > > > ce > > > >>> all sorts of plug-ins would seem to need that ability (to have > their > > > >>> storage hooked up to a datastore or a storage repository).**** > > > >>> > > > >>> ** ** > > > >>> > > > >>> [Edison] It=92s a specific requirement for per volume per LUN case, > > and > > > >>> specific for certain hypervisors(seems KVM doesn=92t need to > create a > > > st= > > > > orage > > > >>> pool when using iscsi LUN), so the storage framework will not deal > > > with = > > > > it > > > >>> right now.**** > > > >>> > > > >>> ** ** > > > >>> > > > >>> ** ** > > > >>> > > > >>> Thanks for your time, Edison! :)**** > > > >>> > > > >>> ** ** > > > >>> > > > >>> On Thu, Mar 21, 2013 at 4:45 PM, Edison Su <edison...@citrix.com> > > > wrote:= > > > > * > > > >>> *** > > > >>> > > > >>> Feedback/comments are appreciated, need to know your input from > > storage > > > >>> vendor point of view.**** > > > >>> > > > >>> **** > > > >>> > > > >>> *From:* Vladimir Popovski [mailto:vladi...@zadarastorage.com] > > > >>> *Sent:* Thursday, March 21, 2013 11:52 AM > > > >>> *To:* Edison Su; cloudstack**** > > > >>> > > > >>> > > > >>> *Cc:* mike.tutkow...@solidfire.com > > > >>> *Subject:* RE: Storage Subsystem 2.0 plugin docs**** > > > >>> > > > >>> **** > > > >>> > > > >>> Hi Edison,**** > > > >>> > > > >>> **** > > > >>> > > > >>> Thank you for the reply. We will check it out.**** > > > >>> > > > >>> **** > > > >>> > > > >>> Regards,**** > > > >>> > > > >>> -Vladimir**** > > > >>> > > > >>> **** > > > >>> > > > >>> **** > > > >>> > > > >>> *From:* Edison Su [mailto:edison...@citrix.com] > > > >>> *Sent:* Thursday, March 21, 2013 11:36 AM > > > >>> *To:* 'Vladimir Popovski'; cloudstack > > > >>> *Cc:* mike.tutkow...@solidfire.com > > > >>> *Subject:* RE: Storage Subsystem 2.0 plugin docs**** > > > >>> > > > >>> **** > > > >>> > > > >>> **** > > > >>> > > > >>> **** > > > >>> > > > >>> *From:* Vladimir Popovski [mailto:vladi...@zadarastorage.com > > > <vladimir@za= > > > > darastorage.com>] > > > >>> > > > >>> *Sent:* Wednesday, March 20, 2013 9:05 AM > > > >>> *To:* cloudstack > > > >>> *Cc:* mike.tutkow...@solidfire.com; Edison Su > > > >>> *Subject:* Storage Subsystem 2.0 plugin docs**** > > > >>> > > > >>> **** > > > >>> > > > >>> Hi All,**** > > > >>> > > > >>> **** > > > >>> > > > >>> Thank you for a great work on CloudStack! We are interested in > > > >>> integrating CS with our storage system and started to look at your > > > >>> documentation and storage-related code. I see that Mike from > > SolidFire > > > >>> started working on something similar some time ago and Edison even > > > creat= > > > > ed > > > >>> an empty plugin for it (in Nov=9212?).**** > > > >>> > > > >>> **** > > > >>> > > > >>> We have couple of questions related to that:**** > > > >>> > > > >>> - Is there any documentation about plugins (except of > > > >>> https://cwiki.apache.org/CLOUDSTACK/storage-subsystem-20.html)**** > > > >>> > > > >>> [Edison] There are not much docs about the plugins other than the > > above > > > >>> link. See below.**** > > > >>> > > > >>> - Are there any exemplary plugins for primary & secondary > > > >>> datastores? Was the SolidFire plugin ever finished?**** > > > >>> > > > >>> [Edison] yesterday, I checked in some code to separate existing > > > >>> cloudstack storage code into a standalone maven project, called: > > > >>> cloud-plugin-storage-volume-default, which can give you an example > > how > > > a > > > >>> storage plugin will look like.**** > > > >>> > > > >>> - How to activate a new plugin and use it (at least > through > > > >>> CLIs/APIs)**** > > > >>> > > > >>> [Edison] First, put a bean configuration in client/tomcatconf/ > > > >>> componentContext.xml.in for your plugin provider class, like:**** > > > >>> > > > >>> <bean id=3D"ClassicalPrimaryDataStoreProvider" > > > >>> > > > > class=3D"org.apache.cloudstack.storage.datastore.provider.CloudStackPrim= > > > > aryDataStoreProviderImpl"> > > > >>> **** > > > >>> > > > >>> </bean>**** > > > >>> > > > >>> Second, when adding a data store into cloudstack, with an extra > > > paramete= > > > > r > > > >>> in createstoragepoolcmd: provider=3Dyour-provider-name, > > > >>> liststorageproviderscmd can list all the registered providers in > mgt > > > ser= > > > > ver. > > > >>> **** > > > >>> > > > >>> **** > > > >>> > > > >>> **** > > > >>> > > > >>> - How to integrate it with the UI**** > > > >>> > > > >>> There is no UI part of example code for storage yet, the idea is to > > use > > > >>> pluggable UI( > > > >>> > > > > > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/UI+Plugin+Tutoria= > > > > l), > > > >>> for each storage provider may need a separate UI to add a storage. > > For > > > >>> example, in adding primary storage ui, there will be a drop down > > list, > > > s= > > > > how > > > >>> all the registered providers, if user selects one of the drop down > > > list, > > > >>> then UI will pop up a diagram, based on providers=92 pluggable ui, > > > then = > > > > user > > > >>> can type whatever information needed for a storage(e.g. nfs server, > > nfs > > > >>> path, if its nfs). At the end, UI will call createstoragepoolcmd to > > > >>> register a storage into cloudstack.**** > > > >>> > > > >>> **** > > > >>> > > > >>> Thanks,**** > > > >>> > > > >>> -Vladimir**** > > > >>> > > > >>> **** > > > >>> > > > >>> **** > > > >>> > > > >>> -------**** > > > >>> > > > >>> Vladimir Popovski**** > > > >>> > > > >>> VP, Cloud Operations**** > > > >>> > > > >>> Zadara Storage > > > >>> (949) 677-2095**** > > > >>> > > > >>> vladi...@zadarastorage.com**** > > > >>> > > > >>> www.zadarastorage.com**** > > > >>> > > > >>> **** > > > >>> > > > >>> **** > > > >>> > > > >>> > > > >>> > > > >>> **** > > > >>> > > > >>> ** ** > > > >>> > > > >>> -- > > > >>> *Mike Tutkowski***** > > > >>> > > > >>> *Senior CloudStack Developer, SolidFire Inc.***** > > > >>> > > > >>> e: mike.tutkow...@solidfire.com**** > > > >>> > > > >>> o: 303.746.7302**** > > > >>> > > > >>> Advancing the way the world uses the cloud< > > > http://solidfire.com/solution= > > > > /overview/?video=3Dplay> > > > >>> *=99***** > > > >> > > > >> > > > >> > > > >> -- > > > >> *Mike Tutkowski* > > > >> *Senior CloudStack Developer, SolidFire Inc.* > > > >> e: mike.tutkow...@solidfire.com > > > >> o: 303.746.7302 > > > >> Advancing the way the world uses the cloud< > > > http://solidfire.com/solution/= > > > > overview/?video=3Dplay> > > > >> *=99* > > > > > > > > > > > > > > > > --=20 > > > > *Mike Tutkowski* > > > > *Senior CloudStack Developer, SolidFire Inc.* > > > > e: mike.tutkow...@solidfire.com > > > > o: 303.746.7302 > > > > Advancing the way the world uses the > > > > cloud<http://solidfire.com/solution/overview/?video=3Dplay> > > > > *=99* > > > > > > > > --f46d044785339cc8d004d8c69b56-- > > > > > > > > > > > -- > > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: mike.tutkow...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*