Yes, there is no immediate change to s3-backed storage code on master branch after javelin is merged into master. As I haven't glue the new storage code on javelin branch with storage related api calls yet, so all the existing storage code on master will/should work as it is. After the merge, we can decide when to use the new storage framework code. I think all we agree on that the storage code needs to be refactored, and if then we agree on how to do it, that will be the time we can switch to new storage code.
> -----Original Message----- > From: John Burwell [mailto:jburw...@basho.com] > Sent: Tuesday, January 08, 2013 10:44 AM > To: cloudstack-dev@incubator.apache.org > Subject: Re: [MERGE] Merge Javelin branch into master > > Edison, > > So the current changes for S3-backed Secondary Storage will not be impacted > by the Javelin's new storage architecture? > > Thanks, > -John > > On Jan 8, 2013, at 1:21 PM, Edison Su <edison...@citrix.com> wrote: > > > > > > >> -----Original Message----- > >> From: John Burwell [mailto:jburw...@basho.com] > >> Sent: Tuesday, January 08, 2013 9:13 AM > >> To: cloudstack-dev@incubator.apache.org > >> Subject: Re: [MERGE] Merge Javelin branch into master > >> > >> All, > >> > >> Will this merge be pre or post 4.1.0? I am concerned regarding the > >> S3-backed > > > > Plan before 4.1.0. > > > >> Secondary Storage feature. Looking at this branch, the work done to > >> support > >> S3 does not appear to compatible with the new storage architecture, > >> and I don't think there is enough time before 31 Jan 2013 to > >> retrofit. I also have > > > > The existing storage code on master will not be changed, as the most of our > changes on javelin branch are in the fresh new maven projects. > > > >> design concerns which I raise on a separate thread. > > > > > > I'd like to know your comments on the design. > > > >> > >> Thanks, > >> -John > >> > >> On Jan 8, 2013, at 12:08 PM, Alex Huang <alex.hu...@citrix.com> wrote: > >> > >>>> The problem that Howie is talking about is that none of our > >>>> projects are structured in the "standard" maven layout. This isn't > >>>> just a test source issue. > >>>> > >>> I'm saying maven have a way to accommodate for that by specifying > >>> exactly > >> where the directory should be in the pom.xml. > >>> > >>> Like I said though, I don't know why it doesn't follow standard layout. > >> Maybe it was just easier to do the maven conversion this way? I > >> think all the directories in javelin has follow the current layout in > >> 4.0 as well. We can make all of the javelin directories follow the > >> standard if there was no clear call on how to layout the structures > originally. > >>> > >>> --Alex > >
