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, Chris
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 – Clou
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
wrote:
> I think I'll look into a version of (2). The difference being that I think
> usi
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 va
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
wrote:
> Well, i
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
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 re
On 10/04/2013 10:36 AM, Edison Su wrote:
How to use the way spring 4.0 did:
https://jira.springsource.org/browse/SPR-5574?
http://stackoverflow.com/questions/16967971/spring-ordered-list-of-beans
Add order in bean.
That is a spring specific API/interface. In general we should never
using S
>> From: SuichII, Christopher [mailto:chris.su...@netapp.com]
>> Sent: Thursday, October 03, 2013 9:02 PM
>> To:
>> Subject: Re: [PROPOSAL] Modularize Spring
>>
>> Sure - I could see that working. Anyone have thoughts whether an enum
>> could be used inst
> -Original Message-
> From: SuichII, Christopher [mailto:chris.su...@netapp.com]
> Sent: Thursday, October 03, 2013 9:02 PM
> To:
> Subject: Re: [PROPOSAL] Modularize Spring
>
> Sure - I could see that working. Anyone have thoughts whether an enum
> could be us
Sure - I could see that working. Anyone have thoughts whether an enum could be
used instead of an integer? That way we can provide categories or a well
defined scale (like 0-5)? If we give them free range of 1-100 (or any integer
range), I imagine people will likely go to the extremes and just u
Could it be just as simple as the canhandle() returns an int and not Boolean.
So the ancient would return 1 but if the netapp matches it returns 100. If it
does not handle at all you return -1. This effectively gives you
prioritization. So the calling code would still loop through all strate
Thanks for the quick reply.
After talking with Edison, I think what we could do is allow the strategies to
either specify a priority or 'type' and then order them by that when they are
loaded. For example, we could have an enum of types like 'PLUGIN, HYPERVISOR
and DEFAULT' so that we can make
I forgot to mention about canHandle() ordering. For extensions, it
should be preferred that we do not rely on loaded or configured order.
The canHandle() implementation should assume that they're may be any
order. So having said that, I looked at XenServerSnapshotStrategy and
its canHandle() is
Chris,
I've updated the wiki [1]. Copying from the wiki
"Extensions are automatically discovered based on the interfaces they
implement and which module is their parent. For example, if you place
a storage extension in a child module of the network module, it will
not be discovered. Additionally
eems the only extra work is adding a property file that
specifies
parent context and current context name, it's not much complex.
BTW: any reason for working on repo outside ACS?
-----Original Message-
From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
Sent: Wednesday, Sept
to our necessary default level.
>>>>>>>
>>>>>>> I know our situation is a bit different than the current plug in
>>>>>>>model, but I think it is something we, as a community, are going to
>>>>>>>begin seeing more of. For a variety
and kept separate from the
>>>>>>ACS source tree. We want our users to be able to simply drop in our
>>>>>>jar
>>>>>>file to the CS directory or run and installer and have it picked up by
>>>>>>the MS upon a restart.
>>>>>
t;>>>> >> cutting to
>>>>> >>> most of ACS. So the modules it contributes to are as follows
>>>>> >>>
>>>>> >>>
>>>>>resources/META-INF/cloudstack/baremetal-storage/spring-context.xml
>
t; --
>>>> Chris Suich
>>>> chris.su...@netapp.com
>>>> NetApp Software Engineer
>>>> Data Center Platforms Cloud Solutions
>>>> Citrix, Cisco & Red Hat
>>>>
>>>> On Sep 18, 2013, at 6:44 PM, Darren Shepherd
>>
>> > I'm not a committer
>>> >
>>> >
>>> > On Wed, Sep 18, 2013 at 3:24 PM, Frank Zhang
>>> wrote:
>>> >
>>> >> Well. The codes explain more than words.
>>> >> It seems the only extra work is add
e codes explain more than words.
>> >> It seems the only extra work is adding a property file that specifies
>> >> parent context and current context name, it's not much complex.
>> >> BTW: any reason for working on repo outside ACS?
>> >>
>&
>> It seems the only extra work is adding a property file that specifies
> >> parent context and current context name, it's not much complex.
> >> BTW: any reason for working on repo outside ACS?
> >>
> >>> -Original Message-
> >>&
uch complex.
>>> BTW: any reason for working on repo outside ACS?
>>>
>>>> -Original Message-
>>>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>>>> Sent: Wednesday, September 18, 2013 2:43 PM
>>>> To: dev@clouds
t much complex.
>> BTW: any reason for working on repo outside ACS?
>>
>>> -Original Message-
>>> From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
>>> Sent: Wednesday, September 18, 2013 2:43 PM
>>> To: dev@cloudstack.apache.org
>>&g
on for working on repo outside ACS?
>
> > -Original Message-
> > From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
> > Sent: Wednesday, September 18, 2013 2:43 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [PROPOSAL] Modularize Spring
> >
&
en Shepherd [mailto:darren.s.sheph...@gmail.com]
> Sent: Wednesday, September 18, 2013 2:43 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Modularize Spring
>
> If you want to see this all working you can just fetch the "no-at-db4"
> branch at https://github.com/ibuildthecl
ependency ?
>
> > -Original Message-
> > From: Darren Shepherd [mailto:darren.s.sheph...@gmail.com]
> > Sent: Wednesday, September 18, 2013 11:53 AM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [PROPOSAL] Modularize Spring
> >
> > I'm
.@gmail.com]
> Sent: Wednesday, September 18, 2013 11:53 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Modularize Spring
>
> I'm not for OSGi either, but contexts are quite useful and will lead to better
> things. First off, we don't want one gigantic
use
> of some components
> is not making much sense to me. If a plugin not following guide(if we have
> it) we should kick it out, instead of making obstacles for 99% good people.
>
>
>
> > -Original Message-
> > From: Darren Shepherd [mailto:darren.s.sheph...
2013 10:33 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Modularize Spring
>
> Right, component isn't a thing. I probably shouldn't use that term. I want
> to
> standarize on the naming convention of plugin, module, and extension. It is
> explain
Right, component isn't a thing. I probably shouldn't use that term. I
want to standarize on the naming convention of plugin, module, and
extension. It is explained a bit on the wiki [1] but I'll try to do a
little better job here. So a plugin is basically a jar. A jar contains
multiple modules
Are you referring to what I have on review board? Any requests I have on
review board at the moment have no interdependencies. They are just a
bunch of random things I found while doing analysis and work for this
proposal.
Darren
On Wed, Sep 18, 2013 at 4:41 AM, Daan Hoogland wrote:
> Darren,
Darren,
I had a quick look at your four submissions, Is there no dependency
between them? if so, can you add those to the review requests?
thanks,
Daan
On Wed, Sep 18, 2013 at 1:25 PM, Daan Hoogland wrote:
> sounds great Darren,
>
> By component, you mean maven project or some larger chunk like
sounds great Darren,
By component, you mean maven project or some larger chunk like
distribution package? (did i miss this definition somewhere or do we
define the components now?)
regards,
Daan
On Wed, Sep 18, 2013 at 12:10 AM, Darren Shepherd
wrote:
> Currently ACS code is fairly modular in t
35 matches
Mail list logo
