cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: [PROPOSAL] Modularize Spring
Date Fri, 04 Oct 2013 17:36:21 GMT


> -----Original Message-----
> From: SuichII, Christopher [mailto:Chris.Suich@netapp.com]
> Sent: Thursday, October 03, 2013 9:02 PM
> To: <dev@cloudstack.apache.org>
> Subject: Re: [PROPOSAL] Modularize Spring
> 
> 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 use 0
> for can't handle, 1 for low priority (default) and 100 for high priority (storage
> providers). We still have the problem of handling conflicts, or implementers
> who return the same value. However, I'm not sure there is much we can do
> beyond selecting the first implementation that we come across with the
> highest priority. We should document and suggest that implementations
> ensure their canHandle() method is as intelligent as possible and only takes
> control of operations they are truly authorities on.

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.

> 
> -Chris
> --
> Chris Suich
> chris.suich@netapp.com
> NetApp Software Engineer
> Data Center Platforms - Cloud Solutions
> Citrix, Cisco & Red Hat
> 
> On Oct 3, 2013, at 7:44 PM, Darren Shepherd <darren.s.shepherd@gmail.com>
> wrote:
> 
> > 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 strategies each time looking for
> the best match.  I don't want the priority to be determined at load time as
> that is less flexible.
> >
> > Darren
> >
> >> On Oct 3, 2013, at 5:42 PM, "SuichII, Christopher"
> <Chris.Suich@netapp.com> wrote:
> >>
> >> 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 sure plugins are asked
> canHandle() first, then hypervisor implementations, then finally resort to the
> default/ancient implementation. This 'type' or 'category' could be specified
> as a bean parameter or as part of the strategy/provider interface. Any
> thoughts on which are better?
> >>
> >> The problem with just making canHandle() more intelligent is that we do
> need some kind of ordering. Ideally, the non-default implementations
> should be asked first, then fall back onto the stock implementations. You saw
> the problem yourself - the XenServerSnapshotStrategy just says it will handle
> all requests, so if a non-standard strategy wants to be given a chance, it must
> be asked before the hypervisor or ancient implementation.
> >>
> >> Alternatively if this matches the same usage of the global configuration
> ordering system, we could add in the storage subsystem strategies and
> providers.
> >>
> >> The reason for log4j changes is that we may want to enable a different
> level of verbosity by default. Our support organization likes to have very
> verbose logs to assist them in triaging support issues. The lowest level log4j
> categories are 'com.cloud', 'org' and 'net' and those are set to DEBUG and
> INFO. Even if we add a line for 'com', the default value should not be 'TRACE'
> like we would like ours to be. I'm not all that great with log4j, though, so
> maybe I'm missing a simpler solution.
> >>
> >> I'll try to keep an eye on the commands.properties/rbac stuff - that is
> good to know.
> >>
> >> Thanks,
> >> Chris
> >> --
> >> Chris Suich
> >> chris.suich@netapp.com
> >> NetApp Software Engineer
> >> Data Center Platforms - Cloud Solutions Citrix, Cisco & Red Hat
> >>
> >>> On Oct 3, 2013, at 4:30 PM, Darren Shepherd
> <darren.s.shepherd@gmail.com> wrote:
> >>>
> >>> 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 brilliantly implemented as "return true;"
> >>>
> >>> Can we look at making the strategies order independent and not
> >>> having another order configuration parameter?
> >>>
> >>> Darren
> >>>
> >>> On Thu, Oct 3, 2013 at 4:26 PM, Darren Shepherd
> >>> <darren.s.shepherd@gmail.com> wrote:
> >>>> 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, depending on the
> >>>> extension, the ordering may be important in how they extension is
> >>>> used. For the extensions that ordering is important there is also a
> >>>> "Global Configuration" setting for the ordering. The value of the
> >>>> setting is a comma seperated list like
> >>>> SHA256SALT,MD5,LDAP,PLAINTEXT. The values are the names of the
> >>>> extension. The name will be the result of getName(), if the bean
> >>>> implements the Named interface, or the sort class name (ie
> getClass().getSimpleName())."
> >>>>
> >>>> I setup all the extensible types based on what was in
> >>>> componentContext.xml and also trial an error.  The types you have
> >>>> mentioned were not in componetContext.xml so I missed them.  It
> >>>> works today, but is not properly extensible.  I will update the
> >>>> configuration and wiki today.
> >>>>
> >>>> I've haven't made progress on the commands.properties as I realized
> >>>> it will overlap with the rbac work being done.  I will start a
> >>>> thread regarding that so maybe it will be address in the rbac work.
> >>>>
> >>>> Regarding log4j.  First, why do you have to change that?
> >>>> Regardless, at the end of the day you are limited to whatever log4j
can
> provide.
> >>>> So log4j AFAIK does not support multiple log4j config files so the
> >>>> best we can do is allow somebody to supply a different log4j config
> >>>> file and configure cloudstack to use that.  One of the things I
> >>>> don't particularily like is that ACS forces log4j to its own
> >>>> configuration file and will not allow the regular log4j config
> >>>> discovery.  So what I could do is add a JVM property like
> >>>> -Dcloudstack.log4jstandardconfig that will disable the ACS behavior
> >>>> of configuring log4j and then you can use the log4j standard approach
> [2].
> >>>>
> >>>> Darren
> >>>>
> >>>> [1]
> >>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions
> >>>> [2] http://logging.apache.org/log4j/1.2/manual.html
> >>>>
> >>>> On Thu, Oct 3, 2013 at 3:29 PM, SuichII, Christopher
> >>>> <Chris.Suich@netapp.com> wrote:
> >>>>> Darren,
> >>>>>
> >>>>> I read through this thread and your docs on the wiki, but I'd
> appreciate it if you could answer a couple questions for me:
> >>>>>
> >>>>> -When creating an extension, such as a DataStoreProvider, those
> items are currently added into the list of providers for the appropriate bean,
> such as:
> >>>>> <bean id="dataStoreProviderManager"
> >>>>>
> >>>>> class="org.apache.cloudstack.storage.datastore.provider.DataStoreP
> >>>>> roviderManagerImpl">
> >>>>>  <property name="providers">
> >>>>>    <list merge="true">
> >>>>>      <ref bean="cloudStackPrimaryDataStoreProviderImpl"/>
> >>>>>      <ref local="cloudStackImageStoreProviderImpl"/>
> >>>>>      <ref local="s3ImageStoreProviderImpl"/>
> >>>>>      <ref local="swiftImageStoreProviderImpl"/>
> >>>>>      <ref local="solidFireDataStoreProvider"/>
> >>>>>    </list>
> >>>>>  </property>
> >>>>> </bean>
> >>>>>
> >>>>> So, how do we add our bean to that list?
> >>>>>
> >>>>> -There are a number of extensions that are not currently listed,
such
> as DataMotionStrategy, SnapshotStrategy, etc. Is it a problem that those are
> omitted from
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Extensions?
> >>>>>
> >>>>> -I know somewhere in this thread you talked about the order of
> beans, but can you document how the ordering or precedence works in the
> wiki? For example, if I create a DataMotionStrategy, how do I ensure that my
> strategy's canHandle() method is invoked before the
> AncientDataStoreStrategy?
> >>>>>
> >>>>> -Is there any progress on modularizing commands.properties and the
> log4j configuration?
> >>>>>
> >>>>> Thanks,
> >>>>> Chris
> >>>>> --
> >>>>> Chris Suich
> >>>>> chris.suich@netapp.com<mailto:chris.suich@netapp.com>
> >>>>> NetApp Software Engineer
> >>>>> Data Center Platforms - Cloud Solutions Citrix, Cisco & Red
Hat
> >>


Mime
View raw message