Sounds great. What's on the spring modularization will support this (obviously the storage framework needs to handle the canHandle logic), but it seems a lot of the storage code is being refactored, so we'll probably have to do a nasty merge.
Darren On Wed, Oct 9, 2013 at 6:03 PM, SuichII, Christopher <chris.su...@netapp.com> wrote: > Yep, that's the idea. In fact, we really need it to be dynamic so that the > strategy or provider can respond depending on the action. For example, > snapshotting may be supported while reverting may not be. > > -- > Chris Suich > chris.su...@netapp.com > NetApp Software Engineer > Data Center Platforms – Cloud Solutions > Citrix, Cisco & Red Hat > > On Oct 9, 2013, at 8:01 PM, Darren Shepherd <darren.s.sheph...@gmail.com> > wrote: > >> I think I'm fine with that. Is the enum type return dynamically at >> runtime. So the API would be something like "PlugInPriority >> canHandle(...)"? >> >> Darren >> >> On Wed, Oct 9, 2013 at 1:13 PM, SuichII, Christopher >> <chris.su...@netapp.com> wrote: >>> I think I'll look into a version of (2). The difference being that I think >>> using an int is too large of a range and provides unnecessary granularity. >>> If two strategies or providers both have snapshot strategies, they are both >>> simply going to return the max int. However, if we use an enum with values >>> like: >>> >>> HIGHEST, PLUGIN, HYPERVISOR, DEFAULT and NO, (HIGHEST would be reserved for >>> unforeseen future use, testing, simulators, etc.) >>> >>> then we allow strategies and providers to fall in the same bucket. All >>> strategies and providers would be sorted and asked to handle operations in >>> that order. Ultimately, this requires that plugins do their best to >>> determine whether they can actually handle an operation, because if two say >>> they can, there is no way for the MS to intelligently choose between the >>> two. >>> >>> -- >>> Chris Suich >>> chris.su...@netapp.com >>> NetApp Software Engineer >>> Data Center Platforms – Cloud Solutions >>> Citrix, Cisco & Red Hat >>> >>> On Oct 4, 2013, at 6:10 PM, Darren Shepherd <darren.s.sheph...@gmail.com> >>> wrote: >>> >>>> Sure, I'm open to suggestions. Basically I think we've discussed >>>> >>>> 1) Global Setting >>>> 2) canHandle() returns an int >>>> 3) Strategy has an enum type assigned >>>> >>>> I'm open to all three, I don't have much vested interest in this. >>>> >>>> Darren >>>> >>>> On Fri, Oct 4, 2013 at 3:00 PM, SuichII, Christopher >>>> <chris.su...@netapp.com> wrote: >>>>> Well, it seems OK, but I think we should keep on discussing our options. >>>>> One concern I have with the global config approach is that it adds manual >>>>> steps for 'installing' extensions. Each extension must have installation >>>>> instructions to indicate which global configurations it must be included >>>>> in and where in that list it should be put (and of course, many extension >>>>> are going to say that they should be at the front of the list). >>>>> >>>>> -Chris >>>>> -- >>>>> Chris Suich >>>>> chris.su...@netapp.com >>>>> NetApp Software Engineer >>>>> Data Center Platforms – Cloud Solutions >>>>> Citrix, Cisco & Red Hat >>>>> >>>>> On Oct 4, 2013, at 12:12 PM, Darren Shepherd >>>>> <darren.s.sheph...@gmail.com> wrote: >>>>> >>>>>> On 10/04/2013 11:58 AM, SuichII, Christopher wrote: >>>>>>> Darren, >>>>>>> >>>>>>> I think one of the benefits of allowing the priority to be specified in >>>>>>> the xml is that it can be configured after deployment. If for some >>>>>>> reason two strategies or providers conflict, then their priorities can >>>>>>> be changed in XML to resolve the conflict. I believe the Spring @Order >>>>>>> annotation an be specified in XML, not just as an annotation. >>>>>>> >>>>>>> -Chris >>>>>>> >>>>>> >>>>>> I would *prefer* extensions to be order independent, but if we determine >>>>>> they are order dependant, then that is fine too. So if we conclude that >>>>>> the simplest way to address this is to order the Strategies based on >>>>>> configuration, then I will add an ordering "global configuration" as >>>>>> described at >>>>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions. >>>>>> >>>>>> Does the order configuration setting approach seem fine? >>>>>> >>>>>> Darren >>>>> >>> >
