Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of jburwell@basho.com designates
 209.85.216.170 as permitted sender)
From: John Burwell <jburwell@basho.com>
Content-Type: multipart/alternative;
 boundary="Apple-Mail=_643B8CA6-238C-483F-AF8D-22AB303659D0"
Message-Id: <B9D496FF-12AC-4B06-9233-971538CDA624@basho.com>
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: [MERGE]object_store branch into master
Date: Thu, 23 May 2013 10:20:10 -0400
References: <CDC28CDD.3C8EE%min.chen@citrix.com>
To: dev@cloudstack.apache.org
In-Reply-To: <CDC28CDD.3C8EE%min.chen@citrix.com>

--Apple-Mail=_643B8CA6-238C-483F-AF8D-22AB303659D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Min,

The com.cloud.storage.template.S3TemplateDownloader is directly =
accessing the S3 API using HTTP client.

Thanks,
John

On May 22, 2013, at 5:57 PM, Min Chen <min.chen@citrix.com> wrote:

> John,
>=20
> 	Can you clarify a bit on your last comment about directly =
accessing S3
> HTTP API? We are only invoking routines in S3Utils to perform =
operations
> with S3, not invoke any REST api if that is what you meant.
>=20
> 	Thanks
> 	-min
>=20
> On 5/22/13 2:49 PM, "John Burwell" <jburwell@basho.com> wrote:
>=20
>> Edison,
>>=20
>> For changes that take as long as described, it should be expected =
that
>> the review will take a proportional amount of time.  In future
>> releases, we should think through ways to divide changes such as =
these
>> into a set of smaller patches submitted throughout the course of the
>> release cycle.
>>=20
>> So far, I can say I am very concerned about failure scenarios and
>> potential race conditions around the NFS cache. However, I am only a
>> quarter of the way through the code so my concerns may be resolved by
>> the end of the process.
>>=20
>> I am also concerned about the correctness S3 implementation.  Why did
>> you choose to directly access the S3 HTTP API rather using the client
>> library?
>>=20
>> Thanks,
>> -John
>>=20
>> On May 22, 2013, at 5:25 PM, Edison Su <Edison.su@citrix.com> wrote:
>>=20
>>>=20
>>>=20
>>>> -----Original Message-----
>>>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>>> Sent: Wednesday, May 22, 2013 1:26 PM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: Re: [MERGE]object_store branch into master
>>>>=20
>>>> On Wed, May 22, 2013 at 08:15:41PM +0000, Animesh Chaturvedi wrote:
>>>>>=20
>>>>>=20
>>>>>> -----Original Message-----
>>>>>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>>>>> Sent: Wednesday, May 22, 2013 12:08 PM
>>>>>> To: dev@cloudstack.apache.org
>>>>>> Subject: Re: [MERGE]object_store branch into master
>>>>>>=20
>>>>>> On Wed, May 22, 2013 at 07:00:51PM +0000, Animesh Chaturvedi =
wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>> -----Original Message-----
>>>>>>>> From: John Burwell [mailto:jburwell@basho.com]
>>>>>>>> Sent: Tuesday, May 21, 2013 8:51 AM
>>>>>>>> To: dev@cloudstack.apache.org
>>>>>>>> Subject: Re: [MERGE]object_store branch into master
>>>>>>>>=20
>>>>>>>> Edison,
>>>>>>>>=20
>>>>>>>> Thanks, I will start going through it today.  Based on other
>>>>>>>> $dayjob responsibilities, it may take me a couple of days.
>>>>>>>>=20
>>>>>>>> Thanks,
>>>>>>>> -John
>>>>>>> [Animesh>] John we are just a few days away  from 4.2 feature
>>>>>>> freeze, can
>>>>>> you provide your comments by Friday 5/24.   I would like all =
feature
>>>> threads
>>>>>> to be resolved sooner so that we don't have last minute rush.
>>>>>>=20
>>>>>> I'm just going to comment on this, but not take it much =
further...
>>>>>> this type of change is an "architectural" change.  We had =
previously
>>>>>> discussed (on several
>>>>>> threads) that the appropriate time for this sort of thing to hit
>>>>>> master was
>>>>>> *early* in the release cycle.  Any reason that that consensus
>>>>>> doesn't apply here?
>>>>> [Animesh>] Yes it is an architectural change and discussion on =
this
>>>>> started a
>>>> few weeks back already, Min and Edison wanted to get it in sooner =
by
>>>> 4/30
>>>> but it took longer than anticipated in  preparing for merge and
>>>> testing on
>>>> feature branch.
>>>>=20
>>>> You're not following me I think.  See this thread on the Javelin =
merge:
>>>>=20
>>>> http://markmail.org/message/e6peml5ddkqa6jp4
>>>>=20
>>>> We have discussed that our preference is for architectural changes =
to
>>>> hit
>>>> master shortly after a feature branch is cut.  Why are we not doing
>>>> that here?
>>>=20
>>> This kind of refactor takes time, a lot of time. I think I worked on
>>> the merge of primary storage refactor into master and bug fixes =
during
>>> =
March(http://comments.gmane.org/gmane.comp.apache.cloudstack.devel/14469)
>>> , then started to work on the secondary storage refactor in
>>> April(http://markmail.org/message/cspb6xweeupfvpit). Min and I =
finished
>>> the coding at end of April, then tested for two weeks, send out the
>>> merge request at middle of May.
>>> With the refactor, the  storage code will be much cleaner, and the
>>> performance of S3 will be improved, and integration with other =
storage
>>> vendor will be much easier, and the quality is ok(33 bugs fired, =
only 5
>>> left:=20
>>> =
https://issues.apache.org/jira/issues/?jql=3Dtext%20~%20%22Object_Store_Re=
f
>>> actor%22). Anyway, it's up to the community to decide, merge it or =
not,
>>> we already tried our best to get it done ASAP.
>>>=20
>=20


--Apple-Mail=_643B8CA6-238C-483F-AF8D-22AB303659D0--