Yeah, you have good points.

Perhaps we can implement them in 4.3, if it's not possible today.


On Tue, Jun 25, 2013 at 10:36 AM, Prasanna Santhanam <t...@apache.org> wrote:

> yeah that includes the dependant driver and lifecycle of the
> corresponding provider.  So it's a mix of componentInjection and XML
> based configuration. It's just an aesthetic detail to group the
> components together like network plugins. But it's useful to breakout
> plugins as separate blocks altogether.
>
> And it feels like anything that is a 'plugin' shouldn't have its
> configuration in the applicationContext because that couples it with a
> very basic management server config w/o the plugins.
>
> On Tue, Jun 25, 2013 at 08:35:41AM -0600, Mike Tutkowski wrote:
> > What I did was follow Edison's default plug-in as a template and used the
> > inject method to link in my life cycle and driver instances.
> >
> >     @Override
> >
> >     public boolean configure(Map<String, Object> params) {
> >
> >         lifecycle =
> > ComponentContext.inject(SolidFirePrimaryDataStoreLifeCycle.class);
> >
> >         driver = ComponentContext.inject(SolidfirePrimaryDataStoreDriver.
> > class);
> >
> >         listener = ComponentContext.inject(new HypervisorHostListener() {
> >
> >             public boolean hostConnect(long hostId, long poolId) {
> >
> >                 return true;
> >
> >             }
> >
> >
> >             public boolean hostDisconnected(long hostId, long poolId) {
> >
> >                 return true;
> >
> >             }
> >
> >         });
> >
> >
> >         return true;
> >
> >     }
> >
> >
> > On Tue, Jun 25, 2013 at 8:31 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> > > Oh, I see...that's a good question.
> > >
> > > I'll have to defer that one to Edison.
> > >
> > >
> > > On Tue, Jun 25, 2013 at 8:28 AM, Prasanna Santhanam <t...@apache.org
> >wrote:
> > >
> > >> Understood, I've done that. But I was wondering if there was a generic
> > >> way to group all components (driver, lifecycle, provider) of a
> > >> vendor-implementation into a logical spring context like say:
> > >>
> > >> In componentContext.xml.in
> > >>
> > >> <!-- Networking adapters -->
> > >>   <bean id="ipDeployers"
> class="com.cloud.utils.component.AdapterList">
> > >>     <property name="Adapters">
> > >>       <list>
> > >>           <ref bean="elasticLoadBalancerElement"/>
> > >>           <ref bean="VirtualRouter"/>
> > >>           <ref bean="VpcVirtualRouter"/>
> > >>           <ref bean="NiciraNvp"/>
> > >>           <ref bean="InternalLbVm"/>
> > >>       </list>
> > >>     </property>
> > >>   </bean>
> > >>
> > >> On Tue, Jun 25, 2013 at 08:19:40AM -0600, Mike Tutkowski wrote:
> > >> > Hi,
> > >> >
> > >> > Yeah, John Burwell is finishing up the review process for the
> SolidFire
> > >> > plug-in, so - at present - the code is not in master.
> > >> >
> > >> > To try to answer your question, I had to modify the
> > >> > applicationContext.xml.in file.
> > >> >
> > >> > Here is the line I added:
> > >> >
> > >> > <bean id="solidFireDataStoreProvider"
> > >> >
> > >>
> class="org.apache.cloudstack.storage.datastore.provider.SolidfirePrimaryDataStoreProvider"
> > >> > />
> > >> >
> > >> > Talk to you later!
> > >> >
> > >> >
> > >> > On Tue, Jun 25, 2013 at 7:32 AM, Prasanna Santhanam <t...@apache.org
> >
> > >> wrote:
> > >> >
> > >> > > Hi
> > >> > >
> > >> > > I noticed that all the storage providers are plugged in via
> > >> > > applicationContext by default. How does one plugin a custom
> provider -
> > >> > > say for example CompanyXStorageProvider?
> > >> > >
> > >> > > On looking at the SolidFire implementation I found the plugin
> doesn't
> > >> > > actually come into play when running in either OSS or nonOSS mode.
> > >> > > IOW, the plugin isn't injected in either of -
> componentContext.xml.in
> > >> > > / nonossComponentContext.xml.in. Is the merge still in progress?
> > >> > >
> > >> > > Since these are not 'Adapters' so I don't know how to plugin my
> own
> > >> > > storage provider into the contexts - oss/non-oss. Unlike network
> > >> > > elements the DataStoreProvider, DataStoreLifeCycle seem
> independant
> > >> and
> > >> > > don't follow the plugin model. How does this work?
> > >> > >
> > >> > > Thanks,
> > >> > >
> > >> > > --
> > >> > > Prasanna.,
> > >> > >
> > >> > > ------------------------
> > >> > > Powered by BigRock.com
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >> > --
> > >> > *Mike Tutkowski*
> > >> > *Senior CloudStack Developer, SolidFire Inc.*
> > >> > e: mike.tutkow...@solidfire.com
> > >> > o: 303.746.7302
> > >> > Advancing the way the world uses the
> > >> > cloud<http://solidfire.com/solution/overview/?video=play>
> > >> > *?*
> > >>
> > >> --
> > >> Prasanna.,
> > >>
> > >> ------------------------
> > >> Powered by BigRock.com
> > >>
> > >>
> > >
> > >
> > > --
> > > *Mike Tutkowski*
> > > *Senior CloudStack Developer, SolidFire Inc.*
> > > e: mike.tutkow...@solidfire.com
> > > o: 303.746.7302
> > > Advancing the way the world uses the cloud<
> http://solidfire.com/solution/overview/?video=play>
> > > *?*
> > >
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the
> > cloud<http://solidfire.com/solution/overview/?video=play>
> > *?*
>
> --
> Prasanna.,
>
> ------------------------
> Powered by BigRock.com
>
>


-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Reply via email to