I skimmed the code, but since I'm not familiar with the environment, I could
not find where "swift-ring-builder rebalance" is invoked. I'm guessing that
each time you add a device to a ring, a rebalance is also done. Leaving aside
how inefficient that is, the key thing is that the rebalance comm
anyone realises they are vulnerable. With my proposal, once
the system is initially configured (in /etc/swift/proxy-server.conf) there are
no on-going implications.
Regards,
Donagh
-Original Message-
From: McCabe, Donagh
Sent: 17 July 2014 16:47
To: OpenStack Development Mailing List
lto:dolph.math...@gmail.com]
Sent: 17 July 2014 15:30
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Keystone] [Swift] Composite Auth question
On Thu, Jul 17, 2014 at 5:43 AM, McCabe, Donagh wrote:
Hi,
I’m working on the Swift implications of
Hi,
I'm working on the Swift implications of using composite authorization [1] [2].
My question for Keystone developers is : what project-id do we expect the
service token to be scoped to - the service's project or the end-user's
project? When reviewing the Keystone spec, I had assumed the
Marco,
The replication *inside* Swift is not intended to move data between two
different Swift instances -- it's an internal data repair and rebalance
mechanism.
However, there is a different mechanism, called container-to-container
synchronization that might be what you are looking for. It wi
