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.lamo...@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 > dlamo...@netapp.com<mailto:dlamo...@netapp.com> > > > > On Jul 12, 2013, at 12:55 PM, John Burwell > <jburw...@basho.com<mailto:jburw...@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.lamo...@netapp.com<mailto:david.lamo...@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 > dlamo...@netapp.com<mailto:dlamo...@netapp.com><mailto:dlamo...@netapp.com> > > > > On Jul 11, 2013, at 8:09 PM, Mike Tutkowski > <mike.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com><mailto:mike.tutkow...@solidfire.com>> > wrote: > > Yeah, I can log a bug on that. > > > On Thu, Jul 11, 2013 at 4:15 PM, Edison Su > <edison...@citrix.com<mailto:edison...@citrix.com><mailto:edison...@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.tutkow...@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> > 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.su...@netapp.com<mailto:chris.su...@netapp.com><mailto:chris.su...@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.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com><mailto:mike.tutkow...@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.su...@netapp.com<mailto:chris.su...@netapp.com><mailto:chris.su...@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.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com><mailto:mike.tutkow...@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.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com><mailto:mike.tutkow...@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.tutkow...@solidfire.com<mailto:mike.tutkow...@solidfire.com><mailto:mike.tutkow...@solidfire.com> > o: 303.746.7302 > Advancing the way the world uses the > cloud<http://solidfire.com/solution/overview/?video=play> > *™* > > >
