Bug 1041529

Summary:	[RFE][swift]: Support chanaging the ring size
Product:	Red Hat OpenStack	Reporter:	RHOS Integration <rhos-integ>
Component:	RFEs	Assignee:	RHOS Maint <rhos-maint>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	markmc, yeylon
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
URL:	https://blueprints.launchpad.net/swift/+spec/ring-doubling
Whiteboard:	upstream_milestone_none upstream_status_unknown upstream_definition_drafting
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-19 16:56:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description RHOS Integration 2013-12-12 16:50:15 UTC

Cloned from launchpad blueprint https://blueprints.launchpad.net/swift/+spec/ring-doubling.

Description:

This work follows in the steps of previous efforts to allow changes to the ring size during the life of a cluster.
I.e. to allow growing the number of partitions of the swift ring which is set to be 2^part_power.
Such a change can allow a cluster to start small and grow as needed, as it removes the requirement to define number of partitions in advance during initial cluster installation.

The basic idea behind such efforts is that one can double every entry in the ring without changing the placement 
(i.e. such that the same keys will continue to be mapped to the same a/c/o servers). 

As well explained in https://bugs.launchpad.net/swift/+bug/933803, doubling the ring introduces an additional challenge at the a/c/o servers. The a/c/o servers are using the partition number as part of the path in which they store objects. Naively increasing the number of partitions therefore will keep the mapping between the swift devices (server disks) constant but will require restructuring the the directory tree at each device. 

This work seek to resolve that challenge and design a solution that will not require restructuring the the directory tree at each device.



Specification URL (additional information):

None