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