Hello,
On Mon, 21 May 2012 13:34:29 +0200
Chmouel Boudjnah wrote:
> I have sent you a pull request for your swift3 repository :
>
> https://github.com/fujita/swift3/pull/1
Applied, thanks!
> I have added a few files to match a bit more what gholt did in the
> other middlewares and copied the
Hi,
On Mon, 21 May 2012 18:01:04 +0200
Chmouel Boudjnah wrote:
> I sent you a documentation pull req that should generate the sphinx
> doc, It would be nice to generate some static html page of the
> documentation as what Greg has done for his projects for example :
>
> http://gholt.github.co
Hello,
On Tue, 22 May 2012 00:33:50 +0400
Oleg Gelbukh wrote:
> We have a feature for swift3 middleware that we'd like to propose for
> merge.
Nice.
> How we can do this now, when it is split into associated project?
> How has the procedure changed?
I'm not sure that there is official procedu
Open Source Software Computing Project
FUJITA Tomonori
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Hello,
# the mailing list is subscriber only? Sorry if you receive the mail twice.
I've just started playing with swift, implemented block storage
service (iSCSI) on the top of swift:
git://git.kernel.org/pub/scm/linux/kernel/git/tomo/tgt.git swift
The iSCSI daemon provides iSCSI volume to clie
Sorry for the late reply, just got back from vacation.
2010/9/7 Gregory Holt :
> On Sep 6, 2010, at 4:18 AM, FUJITA Tomonori wrote:
>
>> I've just started playing with swift, implemented block storage
>> service (iSCSI) on the top of swift:
>
> This sounds quite
2010/9/14 Gregory Holt :
>> Read-your-writes consistency works nicely for the iSCSI service. We
>> could live with weaker consistency models though.
>
> Swift has the small possibility you'd read older data, even just after
> writing newer data with the same HTTP Keep-Alive connection.
>
> Exampl
On Thu, 31 Mar 2011 00:44:07 -0400
Todd Willey wrote:
> I haven't disagreed with those points. I'm not advocating the removal
> of blueprints or changing the way we select release goals. I only
> don't want to be so strict that we push back against our users instead
> of being their allies. Op
On Thu, 31 Mar 2011 10:02:34 +0200
Soren Hansen wrote:
> 2011/3/31 FUJITA Tomonori :
> > Sounds like the importance of blueprints is overrated. If you look at
> > Linux kernel development (more than ten times developers and
> > development speed, I guess),
>
> T
On Fri, 1 Apr 2011 08:59:58 -0400
Jay Pipes wrote:
> > I think that there is no such 'promise' for reviewing in a large
> > OSS. If your code can't get enough reviewers, your code might be not
> > useful enough for the project. It's sorta evolutionary theory. The
> > better code has the better ch
On Fri, 1 Apr 2011 22:02:02 +0200
Soren Hansen wrote:
> > I already saw
> > the shortage of reviewing (and I even saw that a half-baked feature
> > without enough reviewed was merged and reverted).
>
> Yes! EXACTLY! Because people who ought to be reviewing aren't.
I think that we need to admint
On Thu, 21 Apr 2011 23:41:35 +0200
Soren Hansen wrote:
> I find the rebasing/cherry-picking practice even worse in the Linux
> kernel context due to the patch tagging used there. If I add a
> "Signed-off-by: Soren Hansen" to a patch and someone cherry picks that
> patch or moves it around as part
On Fri, 22 Apr 2011 14:52:30 +0200
Soren Hansen wrote:
> 2011/4/22 FUJITA Tomonori :
>>> I find the rebasing/cherry-picking practice even worse in the Linux
>>> kernel context due to the patch tagging used there. If I add a
>>> "Signed-off-by: Soren Hansen&q
On Tue, 26 Apr 2011 16:35:56 +0200
Soren Hansen wrote:
>> Why can't we simply use the better tool at this moment?
>
> For the sake of the argument, I'll pretend for second that git is a
> better tool. What happens when the bzr developers fix the shortcomins
> we've identified here, and bzr becom
Hello,
Chuck told me at the conference that lunr team are still working on
the reference iSCSI target driver design and a possible design might
exploit device mapper snapshot feature.
I think that the advantage of the dm design is that you don't need to
invent lots about snapshot feature and the
On Mon, 2 May 2011 22:41:32 +
Ron Pedde wrote:
> My experience is that I will peruse mailing list archives, but I will
> rarely *post* to mailing lists. Something about the formality of it or
> the pain of subscribing and unsubscribing (or something!) makes me much
> more reluctant to join a
On Mon, 2 May 2011 15:45:20 -0400
Eric Windisch wrote:
> You're involved in the tgt project and it is the tgt project's
> purgative to add features as seen fit, but are you sure that you
> want to support this feature?
I'm the maintainer so I can add anything useful unless I upset the
existing u
On Mon, 2 May 2011 21:11:22 -0400
Eric Windisch wrote:
> I expect there will be great demand for an implementation of a Swift
> as a block device client. Care should be made in deciding what will
Surely. I also modified tgt to simply store data on Swift. It doesn't
work well due to Swift's week
Thanks for the explanation!
On Mon, 2 May 2011 21:12:22 -0700
Michael Barton wrote:
> What I've been playing with is having a manifest that contains hashes
> of (4mb) chunks for the volume's backups. When a user initiates a new
> backup, dm-snapshot does its thing and gives me a block device.
On Mon, 2 May 2011 21:19:43 -0700
Michael Barton wrote:
> Oh, and I don't know if keeping track of dirty chunks so backups are
> less work is worth putting an indirection layer on top of volumes.
I think that it depends on volume capacity and the frequency of
snapshot creation.
> It's probably
On Mon, 6 Jun 2011 09:59:19 +
Shehjar Tikoo wrote:
> It is not very clear to me whether Lunr will be a replacement for
> Glance
I don't think so.
>or will only be used for supporting application volumes.
I'm not sure the meaning of application volumes but it's a replacement
of the current
ed buckets, which aren't supported in
> * OpenStack
> * s3cmd should work with the Eucalyptus patches (but I'm failing to get
> * it working now)
The fix for s3cmd hasn't been merged yet. The following branch should
work:
https://code.launchpad.net/~fujita-tomonori/swift/s3-au
22 matches
Mail list logo
