cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "SuichII, Christopher" <Chris.Su...@netapp.com>
Subject Re: [PROPOSAL] Modularize Spring
Date Thu, 10 Oct 2013 01:03:56 GMT
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.suich@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.shepherd@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.Suich@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.suich@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.shepherd@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.Suich@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.suich@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.shepherd@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
>>>> 
>> 


Mime
View raw message