Hi All,
I am seeing lot of threads and discussion on large container issues. We
also have a spec (
https://specs.openstack.org/openstack/swift-specs/specs/in_progress/container_sharding.html)
to fix this in the future releases.
I have the container-ring/account-ring on the SSD devices. I star
Hi all,
Given our conversations this morning at the Ops Midcycle about Extended
Maintenance, particularly how projects individually deciding stable maintenance
policies would affect operators, I wanted to pop this to the top of your inbox
again. The thread is actively moving, so it’d be good to
On Thu, Mar 8, 2018 at 2:39 AM, Kirubakaran Kaliannan <
kiru...@zadarastorage.com> wrote:
>
>
> Hi All,
>
>
>
> I am seeing lot of threads and discussion on large container issues. We
> also have a spec (https://specs.openstack.org/openstack/swift-specs/specs/
> in_progress/container_sharding.html
On 3/7/2018 8:43 AM, Thierry Carrez wrote:
mriedem volunteered to work on a TC resolution to define
what we exactly meant by that (the proposal is now being discussed at
https://review.openstack.org/#/c/548916/).
A new revision is now up for this after much discussion in the review
itself and
On 2/5/2018 11:44 PM, Massimo Sgaravatto wrote:
But if I try to specify the long list of projects, I get:a "Value ... is
too long" error message [*].
I can see two workarounds for this problem:
1) Create an host aggregate per project:
HA1 including CA1, C2, ... Cx and with filter_tenant_id=p1
> 2. Dan Smith mentioned another idea such that we could index the
> aggregate metadata keys like filter_tenant_id0, filter_tenant_id1,
> ... filter_tenant_idN and then combine those so you have one host
> aggregate filter_tenant_id* key per tenant.
Yep, and that's what I've done in my request_fil
