cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jessica Tomechak <jessica.tomec...@gmail.com>
Subject Re: Storage Subsystem 2.0 plugin docs
Date Tue, 26 Mar 2013 18:58:46 GMT
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.tutkowski@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 <jburwell@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.tutkowski@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.tutkowski@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.su@citrix.com>
> > wrote:
> > >>
> > >>> ** **
> > >>>
> > >>> ** **
> > >>>
> > >>> *From:* Mike Tutkowski [mailto:mike.tutkowski@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.su@citrix.com>
> > wrote:=
> > > *
> > >>> ***
> > >>>
> > >>> Feedback/comments are appreciated, need to know your input from
> storage
> > >>> vendor point of view.****
> > >>>
> > >>> ****
> > >>>
> > >>> *From:* Vladimir Popovski [mailto:vladimir@zadarastorage.com]
> > >>> *Sent:* Thursday, March 21, 2013 11:52 AM
> > >>> *To:* Edison Su; cloudstack****
> > >>>
> > >>>
> > >>> *Cc:* mike.tutkowski@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.su@citrix.com]
> > >>> *Sent:* Thursday, March 21, 2013 11:36 AM
> > >>> *To:* 'Vladimir Popovski'; cloudstack
> > >>> *Cc:* mike.tutkowski@solidfire.com
> > >>> *Subject:* RE: Storage Subsystem 2.0 plugin docs****
> > >>>
> > >>> ****
> > >>>
> > >>> ****
> > >>>
> > >>> ****
> > >>>
> > >>> *From:* Vladimir Popovski [mailto:vladimir@zadarastorage.com
> > <vladimir@za=
> > > darastorage.com>]
> > >>>
> > >>> *Sent:* Wednesday, March 20, 2013 9:05 AM
> > >>> *To:* cloudstack
> > >>> *Cc:* mike.tutkowski@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****
> > >>>
> > >>> Vladimir@zadarastorage.com****
> > >>>
> > >>> www.zadarastorage.com****
> > >>>
> > >>> ****
> > >>>
> > >>> ****
> > >>>
> > >>>
> > >>>
> > >>> ****
> > >>>
> > >>> ** **
> > >>>
> > >>> --
> > >>> *Mike Tutkowski*****
> > >>>
> > >>> *Senior CloudStack Developer, SolidFire Inc.*****
> > >>>
> > >>> e: mike.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<http://solidfire.com/solution/overview/?video=play>
> *™*
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message