Open Stack

On 08/02/2016 09:36 PM, Christian Schwede wrote:
> Hello everyone,

thanks Christian,

> I'd like to improve the Swift deployments done by TripleO. There are a
> few problems today when deployed with the current defaults:
>
> 1. Adding new nodes (or replacing existing nodes) is not possible,
> because the rings are built locally on each host and a new node doesn't
> know about the "history" of the rings. Therefore rings might become
> different on the nodes, and that results in an unusable state eventually.

one of the ideas for this was to use a tempurl in the undercloud swift 
where to upload the rings built by a single overcloud node, not by the 
undercloud

so I proposed a new heat resource which would permit us to create a 
swift tempurl in the undercloud during the deployment

https://review.openstack.org/#/c/350707/

if we build the rings on the undercloud we can ignore this and use a 
mistral action instead, as pointed by Steven

the good thing about building rings in the overcloud is that it doesn't 
force us to have a static node mapping for each and every deployment but 
it makes hard to cope with heterogeneous environments

> 2. The rings are only using a single device, and it seems that this is
> just a directory and not a mountpoint with a real device. Therefore data
> is stored on the root device - even if you have 100TB disk space in the
> background. If not fixed manually your root device will run out of space
> eventually.

for the disks instead I am thinking to add a create_resources wrapper in 
puppet-swift:

https://review.openstack.org/#/c/350790
https://review.openstack.org/#/c/350840/

so that we can pass via hieradata per-node swift::storage::disks maps

we have a mechanism to push per-node hieradata based on the system uuid, 
we could extend the tool to capture the nodes (system) uuid and generate 
per-node maps

then, with the above puppet changes and having the per-node map and the 
rings download url, we could feed them to the templates, replace with an 
environment the rings building implementation and deploy without further 
customizations

what do you think?
-- 
Giulio Fidente
GPG KEY: 08D733BA | IRC: gfidente