cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: Storage Subsystem 2.0 plugin docs
Date Tue, 26 Mar 2013 23:18:16 GMT
Thanks!
FYI, there are some code at both xen and kvm hypervisor resource code to deal with storage
pool creation.
For example, in CitrixResourceBase-> getNfsSR or getIscsiSR to create a nfs SR or ISCSI
SR. In LibvirtStorageAdaptor, which can create storage pool in libvirt.


From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com]
Sent: Tuesday, March 26, 2013 1:52 PM
To: Edison Su
Cc: cloudstack-dev@incubator.apache.org; Vladimir Popovski
Subject: Re: Storage Subsystem 2.0 plugin docs

Hi Edison,

Sounds good.

I already have code to create a XenServer Storage Repository (and optionally use CHAP credentials)
and I'm working right now on creating a vSphere Datastore.

When I have this working and in a nicer state, I can check in with you to review it and provide
comments.

Once those two hypervisors are handled, I'll move on to KVM and OVM.

Thanks!

On Tue, Mar 26, 2013 at 2:33 PM, Edison Su <Edison.su@citrix.com<mailto:Edison.su@citrix.com>>
wrote:
Yes, code is welcome!!! Currently Only the interface at the management server side is defined.
At the hypervisor resource side, we may need some kind of utility library or another plugin
framework, as John proposed few months ago.

From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com>]
Sent: Monday, March 25, 2013 2:37 PM
To: Edison Su; cloudstack-dev@incubator.apache.org<mailto:cloudstack-dev@incubator.apache.org>;
Vladimir Popovski

Subject: Re: Storage Subsystem 2.0 plugin docs

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<mailto: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<mailto:Edison.su@citrix.com>>
wrote:


From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com<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's driver->createasync will be called when mgt server want to create a volume
on the storage. In the driver's implementation, it can directly call storage box's api, or
send a command to hypervisor host, then call storage box's 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 just 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 since 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's a specific requirement for per volume per LUN case, and specific for certain
hypervisors(seems KVM doesn't need to create a storage 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<mailto: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<mailto:vladimir@zadarastorage.com>]
Sent: Thursday, March 21, 2013 11:52 AM
To: Edison Su; cloudstack

Cc: mike.tutkowski@solidfire.com<mailto: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<mailto:Edison.su@citrix.com>]
Sent: Thursday, March 21, 2013 11:36 AM
To: 'Vladimir Popovski'; cloudstack
Cc: mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com>
Subject: RE: Storage Subsystem 2.0 plugin docs



From: Vladimir Popovski [mailto:vladimir@zadarastorage.com]
Sent: Wednesday, March 20, 2013 9:05 AM
To: cloudstack
Cc: mike.tutkowski@solidfire.com<mailto: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 created
an empty plugin for it (in Nov'12?).

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<http://componentContext.xml.in>
for your plugin provider class, like:

<bean id="ClassicalPrimaryDataStoreProvider" class="org.apache.cloudstack.storage.datastore.provider.CloudStackPrimaryDataStoreProviderImpl">

  </bean>

Second, when adding a data store into cloudstack, with an extra parameter in createstoragepoolcmd:
provider=your-provider-name, liststorageproviderscmd can list all the registered providers
in mgt server.





-          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+Tutorial),
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, show all the registered providers, if
user selects one of the drop down list, then UI will pop up a diagram, based on providers'
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<tel:%28949%29%20677-2095>
Vladimir@zadarastorage.com<mailto:Vladimir@zadarastorage.com>
www.zadarastorage.com<http://www.zadarastorage.com/>





--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com>
o: 303.746.7302<tel:303.746.7302>
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)



--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com>
o: 303.746.7302<tel:303.746.7302>
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)



--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com>
o: 303.746.7302<tel:303.746.7302>
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)



--
Mike Tutkowski
Senior CloudStack Developer, SolidFire Inc.
e: mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com>
o: 303.746.7302
Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>(tm)

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