cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edison Su <Edison...@citrix.com>
Subject RE: [MERGE] Simulator Storage Fixes to master (was Re: How does the plugin model work for storage providers?)
Date Fri, 28 Jun 2013 00:28:17 GMT
Hi Prasanna, thanks for your great effort to get simulator work. I reviewed all your changes,
looks good to me, while there is only one  thing that I don't like: the implementation of
SimulatorImageStoreDriverImpl, so I rewrote it with a simpler implementation. The commit number
is a2ec1daf8422d0a1c789e331a3261b05a4501060, please double check.

> -----Original Message-----
> From: Prasanna Santhanam [mailto:tsp@apache.org]
> Sent: Thursday, June 27, 2013 8:07 AM
> To: CloudStack Dev
> Cc: Edison Su; Min Chen
> Subject: [MERGE] Simulator Storage Fixes to master (was Re: How does the
> plugin model work for storage providers?)
> 
> On Wed, Jun 26, 2013 at 05:18:14PM +0530, Prasanna Santhanam wrote:
> > Reason I needed to do this is because I need to get the simulator to
> > use a separate spring context and override the default
> > CloudstackImageStore bean. The simulator bean has to intercept the
> > template download calls to say everything is present.
> >
> > But looks like the dependency graph for this goes up to the
> > DataMotionService -> DataMotionStrategy -> DataStoreManager ->
> > DataStoreProviderManager -> DataStoreProvider.
> >
> > I will push the changes to a branch for review.
> >
> 
> This is a MERGE request to include the new storage subsystem support for
> the simulator. I'm including this as a merge since it touches some storage
> code (minor setters here and there) and reorganizes the Spring beans in to
> different bean contexts. With this 4.2 can run simulator and we can help
> jclouds run their live tests against the simulator end points as described in [1].
> And Ian to setup his pipeline for the LDAP testing [2]. And of course to get
> checkin tests working again [3]
> 
> I got spring contexts working by overriding the beans loaded by management
> server. I've separated the beans such that OSS hypervisor related beans go
> into componentContext.xml and the VmWare and Solidfire related beans go
> into nonossComponentContext.xml.
> 
> 
> The deployVM, registerTemplate, downloadVolume operations work fine on
> the simulator now along with the checkin tests. I will run some more tests on
> the branch later with devcloud and real hypervisors tomorrow and merge it
> with master if there are no objections.
> 
> branch: simulatorStorageFixes
> rebased on top of current master , will re-rebase if there are any other
> changes/reviews. The review-chunks are in the following commits:
> 
> a6bb56b10dd25b2b248644e0dbb2a0f394499cee Set all templates/volumes to
> Ready in the simulator
> 373dd2b8b9db50c4c5b63ed9ddf419f1296977c1 Don't report back resource
> state to ResourceManagerImpl
> 2488694ca8ed2ff5f54dce26e518be9c2e920aa1 Group storage subsystem
> components for spring
> 724b3f423016546116a1a0fb499fab9f90658523 DataStore - provider, lifecycle,
> driver implementations for simulator
> 
> [1] http://cloudstack.markmail.org/thread/ume76fqka7fi5nfz
> [2] http://markmail.org/message/hpy6vrbmxrpcqywx
> [3] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Marvin+-
> +Testing+with+Python#Marvin-TestingwithPython-
> 
> Thanks,
> 
> --
> Prasanna.,
> 
> ------------------------
> Powered by BigRock.com


Mime
View raw message