Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of Chris.Suich@netapp.com
 designates 216.240.18.76 as permitted sender)
From: "SuichII, Christopher" <Chris.Suich@netapp.com>
To: "<dev@cloudstack.apache.org>" <dev@cloudstack.apache.org>
Subject: Re: [PROPOSAL] Modularize Spring
Thread-Topic: [PROPOSAL] Modularize Spring
Thread-Index: 
 AQHOs/LZLIj4+hybAEqN28tYSCNAF5nL0SCAgABmiQCAAA3gAIAACJkAgAAibgCAAAzegIAAC70AgAAFrACAACIDAIAAFi6AgAag5wCAALyVgIAAIxgAgAAeV4CAAAQSgIAAtkYAgA79GwCAABAHAIAAAT8AgAAT+gCAACIOgIAAFaOAgADjloCAABbqAIAAA9IAgAAu/gCAAAMBgIAHuq8AgAA/14CAABF0gA==
Date: Thu, 10 Oct 2013 01:03:56 +0000
Message-ID: <AE6CE26C-C42A-46CA-B74F-D28B0BB016F7@netapp.com>
References: 
 <CAMCEDC2+qAX=_Ro4pWzc1q64hnA2n1kKMzAcGbm0WPrLB4OjjQ@mail.gmail.com>
 <CE660A15.55359%kelven.yang@citrix.com>
 <CAMCEDC0yVKrji5Vk5e7=HYiAe1Xq+84XF2NoN6aaHh9VfKqDjQ@mail.gmail.com>
 <CAGQtxvZGkvB37m_BK4jJWxYYLa__yPpdGz3J8BcLYYWiWa41Pw@mail.gmail.com>
 <3AAC8EBA-5BFB-4310-B899-89A02A70A7C6@netapp.com>
 <CAMCEDC2nRwz40ch59Ok0A0Uo5_UJPw1p0LG9jHuh--YRqktcWg@mail.gmail.com>
 <CAMCEDC3gTspje5OGhiCmq5WAuXi8ft=15oyb1w0guWSop1oXJg@mail.gmail.com>
 <DA9597F7-27FD-4921-990F-0B24F0A112DD@netapp.com>
 <AAE4D13C-908A-45AE-84D9-DEE807441541@gmail.com>
 <DF0BBEC7-A261-42DE-AD26-2FD0EAE4CFE8@netapp.com>
 <77B337AF224FD84CBF8401947098DD8716AC39@SJCPEX01CL01.citrite.net>
 <0DF63E46-E7BF-41A9-B16F-0CA833ECE25A@netapp.com>
 <524F1302.5070406@gmail.com>
 <1A414B89-6915-43F7-8E8E-66AF35A5316C@netapp.com>
 <CAMCEDC3wYQn9v0GN2fee3Ujx21u5YanqWHUcUxjGjK44bWUztw@mail.gmail.com>
 <6C5E100E-4D83-4468-BED9-0B3B787635FD@netapp.com>
 <CAMCEDC3XQsjsQj7-jzLTSRa5kTNUKpkC6No3UbjsoBGQSQVTYg@mail.gmail.com>
In-Reply-To: 
 <CAMCEDC3XQsjsQj7-jzLTSRa5kTNUKpkC6No3UbjsoBGQSQVTYg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <675D101A72191D43AF62D0388645A913@hq.netapp.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

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, snap=
shotting may be supported while reverting may not be.

--=20
Chris Suich
chris.suich@netapp.com
NetApp Software Engineer
Data Center Platforms =96 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(...)"?
>=20
> Darren
>=20
> 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 thi=
nk using an int is too large of a range and provides unnecessary granularit=
y. If two strategies or providers both have snapshot strategies, they are b=
oth simply going to return the max int. However, if we use an enum with val=
ues like:
>>=20
>> HIGHEST, PLUGIN, HYPERVISOR, DEFAULT and NO, (HIGHEST would be reserved =
for unforeseen future use, testing, simulators, etc.)
>>=20
>> then we allow strategies and providers to fall in the same bucket. All s=
trategies and providers would be sorted and asked to handle operations in t=
hat order. Ultimately, this requires that plugins do their best to determin=
e whether they can actually handle an operation, because if two say they ca=
n, there is no way for the MS to intelligently choose between the two.
>>=20
>> --
>> Chris Suich
>> chris.suich@netapp.com
>> NetApp Software Engineer
>> Data Center Platforms =96 Cloud Solutions
>> Citrix, Cisco & Red Hat
>>=20
>> On Oct 4, 2013, at 6:10 PM, Darren Shepherd <darren.s.shepherd@gmail.com=
> wrote:
>>=20
>>> Sure, I'm open to suggestions.  Basically I think we've discussed
>>>=20
>>> 1) Global Setting
>>> 2) canHandle() returns an int
>>> 3) Strategy has an enum type assigned
>>>=20
>>> I'm open to all three, I don't have much vested interest in this.
>>>=20
>>> Darren
>>>=20
>>> 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 option=
s. One concern I have with the global config approach is that it adds manua=
l 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).
>>>>=20
>>>> -Chris
>>>> --
>>>> Chris Suich
>>>> chris.suich@netapp.com
>>>> NetApp Software Engineer
>>>> Data Center Platforms =96 Cloud Solutions
>>>> Citrix, Cisco & Red Hat
>>>>=20
>>>> On Oct 4, 2013, at 12:12 PM, Darren Shepherd <darren.s.shepherd@gmail.=
com> wrote:
>>>>=20
>>>>> On 10/04/2013 11:58 AM, SuichII, Christopher wrote:
>>>>>> Darren,
>>>>>>=20
>>>>>> 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 reas=
on two strategies or providers conflict, then their priorities can be chang=
ed in XML to resolve the conflict. I believe the Spring @Order annotation a=
n be specified in XML, not just as an annotation.
>>>>>>=20
>>>>>> -Chris
>>>>>>=20
>>>>>=20
>>>>> I would *prefer* extensions to be order independent, but if we determ=
ine they are order dependant, then that is fine too.  So if we conclude tha=
t the simplest way to address this is to order the Strategies based on conf=
iguration, then I will add an ordering "global configuration" as described =
at https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions.
>>>>>=20
>>>>> Does the order configuration setting approach seem fine?
>>>>>=20
>>>>> Darren
>>>>=20
>>=20