cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "La Motta, David" <David.LaMo...@netapp.com>
Subject Re: Specifying Storage Provider for Primary Storage Creation/Registration
Date Tue, 16 Jul 2013 15:32:26 GMT
John,

UI requirements?  A reusable wizard for plugin implementers to leverage, and this has already
been brought up by Chris Suich in another thread.  That would allow for the same look and
feel as other wizards in CS, but what is gathered in the wizard screens is entirely up to
the vendor.  I basic flow for a NetApp-based provisioning wizard, for instance, could be:

Screen 1. Pick the storage controller, the storage virtual machine (a.k.a Vserver) and the
data LIF that will expose the volume
Validate that controller credentials are valid, that the vserver is not offline, and that
the data LIF still exists with a valid root namespace export policy.

Screen 2. Pick your protocol: NFS, iSCSI or FC
Validate that the license for the selected protocol is present on the controller, validate
that the protocol service is enabled.

Screen 3. Select the aggregate where the volume is going to be placed (if NFS); if a SAN protocol
was selected, select the volume where the LUN will be placed, or give the user the ability
to create a brand new volume.  Select thick or thin provisioned, enable dedupe on the vol,
set the auto-grow increment and max value.
Validate there is enough room on the aggregate if thick provisioning; if thin provisioning,
let it rip.  Check volume names and cross reference for duplicates, etc.

Screen 4. Review all settings, and go.
Validate successful creation; on failure rollback and leave things in the state they were
prior to the wizard.

Upon successful completion make the volume available to CloudStack via inter plugin communication
or a REST call, and call it a day.  If _that_ fails for whatever reason, rollback the provisioned
storage.


That could be one workflow (some details are surely missing).  While we _could_ jam everything
into a huge form to capture all details, it just starts to grow and get out of hand quickly.
 That was the intent of my original email:  give the vendor a way to run a custom UI (ideally
a reusable CS wizard).

So, with all those details in hand, we can offload the info to the storage layer for things
to take place.  I'm not looking any deeper than that  :-)

Does this help?


David La Motta
Technical Marketing Engineer
Citrix Solutions

NetApp
919.476.5042
dlamotta@netapp.com<mailto:dlamotta@netapp.com>



On Jul 16, 2013, at 9:39 AM, John Burwell <jburwell@basho.com<mailto:jburwell@basho.com>>
wrote:

David,

Are you able to share more specific UI requirements?  For example, would it be possible to
describe a basic flow through the UI you require?

My thoughts around the property bag are that it would be available at the lowest levels of
the storage layer-- passed into each driver operation (read, write, clone, copy, delink, destroy,
etc) allowing each physical storage operations to leverage the additional configuration information.
 What deeper layers are you envisioning will need the property bag?

Thanks,
-John

On Jul 16, 2013, at 9:29 AM, "La Motta, David" <David.LaMotta@netapp.com<mailto:David.LaMotta@netapp.com>>
wrote:

John,

The generic properties would fit the bill for a vendor that just wants to provide the metadata
and let the traditional primary-storage workflow take its course.  But, a form with additional
fields may not be enough for a particular implementation, so having the flexibility to display
a custom UI is was what I was going for.  That the generic properties bag is available in
the end to driver operations, that's great, but that will be consumed in a deeper layer than
the UI.  A vendor should be given a bit of freedom on how those properties are gathered.


David La Motta
Technical Marketing Engineer
Citrix Solutions

NetApp
919.476.5042
dlamotta@netapp.com<mailto:dlamotta@netapp.com><mailto:dlamotta@netapp.com>



On Jul 12, 2013, at 12:55 PM, John Burwell <jburwell@basho.com<mailto:jburwell@basho.com><mailto:jburwell@basho.com>>
wrote:

David,

The capability you are describing is the generic properties idea that we discuss at Collab
(see http://markmail.org/message/jtntptrouvvzsdgi for a capture).  Essentially, drivers would
be alb to provide meta-data definition for a property bag associated with DataStore instances.
 This metadata would be used to render additional fields on the UI based on the driver selected.
  We would also add callbacks to the driver to validate the property bag before persisting
it to ensure that validity of its contents.  Finally, this property bag would be passed into
all driver operations -- allowing underlying operations to exploit the additional configuration
information.

What do you think the requirements of such a facility would be?

Thanks,
-John

On Jul 12, 2013, at 10:40 AM, "La Motta, David" <David.LaMotta@netapp.com<mailto:David.LaMotta@netapp.com><mailto:David.LaMotta@netapp.com>>
wrote:

Mike, Edison, et al., this brings up the question of what UI will be displayed when the user
selects a storage vendor's plugin implementation.  In other words, IMO the ideal scenario
is to have the ability to allow the storage plugin's implementer to display a custom UI. 
That way, the traditional add-primary-storage form is replaced with whatever the vendor decides
to provide _to_meet_their_needs_.  This could be a longer form with different fields, a wizard,
basically... anything.

Now, the one-or-nothing approach is a bit draconian, so the new implementation could be a
bit flexible and display the default add-primary-storage form if the vendor isn't providing
a UI.  This also means that a new mechanism has to be added to query a vendor's implementation
to see if a UI is going to be provided or not.

In general, I believe this gives the most flexibility to storage [or any other] plugin implementers,
since it gives them the ability to fulfill a UI request with something a little more custom.
 And I'm not thinking in terms of branding or anything like that, I am thinking in terms of
giving the ability to the vendor to capture other important info to be able to complete the
request in the first place.


David La Motta
Technical Marketing Engineer
Citrix Solutions

NetApp
919.476.5042
dlamotta@netapp.com<mailto:dlamotta@netapp.com><mailto:dlamotta@netapp.com><mailto:dlamotta@netapp.com>



On Jul 11, 2013, at 8:09 PM, Mike Tutkowski <mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com><mailto:mike.tutkowski@solidfire.com><mailto:mike.tutkowski@solidfire.com>>
wrote:

Yeah, I can log a bug on that.


On Thu, Jul 11, 2013 at 4:15 PM, Edison Su <Edison.su@citrix.com<mailto:Edison.su@citrix.com><mailto:Edison.su@citrix.com><mailto:Edison.su@citrix.com>>
wrote:

Definitely, we need to fire a bug for UI to show up all the storage
plugins, when adding primary storage.
Could you help to fire a bug, or fix it?:)

-----Original Message-----
From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com<http://solidfire.com><http://solidfire.com><http://solidfire.com>]
Sent: Thursday, July 11, 2013 1:49 PM
To: dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org><mailto:dev@cloudstack.apache.org>
Subject: Re: Specifying Storage Provider for Primary Storage
Creation/Registration

Oh, I see what you're asking. :)

At present, the GUI only supports the default plug-in (i.e. not the
SolidFire
one).

If you want to specify one that is not the default, it must be done via
the API.


On Thu, Jul 11, 2013 at 2:45 PM, SuichII, Christopher <
Chris.Suich@netapp.com<mailto:Chris.Suich@netapp.com><mailto:Chris.Suich@netapp.com><mailto:Chris.Suich@netapp.com>>
wrote:

But how do you specify it in the UI? The add primary storage popup
doesn't have a field for provider.

Chris

On Jul 11, 2013, at 4:43 PM, Mike Tutkowski
<mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com><mailto:mike.tutkowski@solidfire.com><mailto:mike.tutkowski@solidfire.com>>
wrote:

If you leave it off (it's an optional parameter), you'll get the
default.

If you specify "SolidFire", you'll get mine.

If you'd like to specify the default, it is "DefaultPrimary".

Hope that helps. :)


On Thu, Jul 11, 2013 at 2:39 PM, SuichII, Christopher <
Chris.Suich@netapp.com<mailto:Chris.Suich@netapp.com><mailto:Chris.Suich@netapp.com><mailto:Chris.Suich@netapp.com>>
wrote:

I'm trying to figure out how to specify which storage provider
should be used when creating a new primary storage pool. Th
CreateStoragePoolCmd takes the parameter 'provider' which seems to
be what is used to pick
the
storage provider, but I can't find anywhere in the UI that this can
be specified or added to the createStoragePool API call.

Mike T or Edison (or anyone else), do you know how to actually
specify this?

Thanks,
Chris




--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com><mailto: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)*




--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com><mailto: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)*




--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com<mailto:mike.tutkowski@solidfire.com><mailto: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>
*™*






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