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> > *™* >
