On Tue, Mar 12, 2024 at 10:07 AM <m.victorello@luizalabs.com> wrote:

Is there any plan to support multi-policy containers?

No, containers are expected to only have one policy at a time. There's no roadmap for a per-object storage-policy feature.

Why the container's database have a 'storage_policy_index' column for objects?

That database state is needed for eventual consistency when recreating a container with a different policy. That process is handled by the container-reconciler.

As far as I know the policy index comes from the container (broker.get_info).

That's correct, it's set in container sys-meta when the databases are created.

I don't know that much about changing the policy of a container, i think those are related.

When the policy of a container changes (typically in response to a healed network partition) the proxy-server will start requesting objects from the "new" storage policy; any data in the "old" policy wouldn't be accessible - the objects in the "old" policy won't show up in the container listing. Even with those caveats there may be some use-case for "migrating" the data in an existing container from one policy to another. You can force a container to think its storage-policy "changed" with some direct database timestamp manipulation [1] and the container-reconciler will start moving objects. So far we haven't found a use-case for container policy migration that was amicable to the unbounded unavailability window or written code to in the access tier (proxy) that would support a "fallback" to the old storage policy (PUT/DELETE is easy enough, GET isn't so bad, POST is tricky). 1. https://review.opendev.org/c/openstack/swift/+/800748/11/swift/container/bac... -- Clay Gerrard